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PREFACE 


Multics system administration software controls the use of system resources 
and keeps records about how they are used. It supports rationing of resources, 
provides system security services, and produces usage reports and bills as required. 


The administrative and resource control functions of Multics compose a sizeable 
Subsystem. They are designed to be expanded or optionally bypassed and to allow 
flexibility for each Multics site. 


The Multics system allows a maximum of four administrative identities: the 
project administrator, the registration and accounting administrator (referred 
to as the accounting administrator), the system security administrator, and the 
system administrator. The only administrator each site must have is a system 
administrator. 


The reference manuals for Multics administrators are collectively referred 
to as the Multics Administrators' Manual (MAM). Throughout this document, references 
to the MAM are as follows: 


Document Referenced In Text As 
Project MAM Project 
TOrder No. AK51) 
Registration and Accounting MAM Accounting 
(Order No. AS6B8) 
System MAM System 
(Order No. AK50) 
Resource Control MAM RCP 
(Order No. 
Communications MAM Communications 


Corder No. CC75) 
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Tne MAM Communications is a guide to the operation of the Multics 
Communication System. This manual includes information on terminal types, line 
types, and channel management. 


The Programmer's Reference manual (see below) contains general user 
information about terminal use and communications input/output. Readers of the 
MAM Communications should be familiar with the information in the Programmer's 
Reference, 


One of the responsibilities of the system administrator is specifying 
procedures used by the operators. These procedures and all operator commands 
are ‘described in the Multics Operator's Handbook, Order No. AM81. For 
convenience, this handbook is referenced throughout this document as the MOH. 


The Multics Bulk Input/Output manual (Order No. CC34) contains information 
needed by system administrators and operators for the management of bulk 
input/output. For convenience, this manual is referred to throughout this 
document as Multics Bulk I/O. 


The Multics Communication System manual, Order No. AN85, contains a 
complete description of the software that makes up the Multics Communication 
System, including the portion of it in the Multics supervisor, the software for 
the Front-End Network Processor (FNP), implementation details, and a glossary of 
technical terms specific to the Multics Communication System. 


The following are the primary reference manuals for user’ and system 
programmers of the Multics system. These manuals contain general information 
and are referenced throughout this document. For convenience, these references 
‘are as follows: 


Document Referenced in Text as 
Multics Programmer's Reference Manual Programmer's Reference 
Pe OR PEER NT en 


Multics Commands and Active Functions Commands 
(Order No. AG92) 
Multics Subroutines and I/O Modules Subroutines 


(Order No. AG93) 


Significant Changes in CC75-01B 

Throughout the manual, cross-references have been rectified in those cases 
where the reader is referred to an obsolete manual, and it is not apparent where 
the information can now be found. 


The Multics X.25 interface is now certified for use with TELENET and UNINET 
networks. 


A new command, set_x25_ packet threshold, is described in Section 7. 


The packet threshold and collect parameters of the TIF description for X.25 
channels are included in Appendix A. 


Also documented in Appendix A is the capability to connect to a foreign 
system from a terminal logged into Multics, using a protocol converter. 
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SECTION 1 


OVERVIEW OF MULTICS COMMUNICATION SYSTEM 


The Multics Communication System effects the transfer of data between the 
Multics virtual memory and various remote devices (primarily terminals) over: 
communications channels. This manual is eoncerned with the Multics 
Communication System as it appears to a system administrator, and it also 
discusses the specification and management of channels. For a description of 
the internal workings of the Multics Communication System, see the Multics: 
Communication System Manual, Order Number AN85. 


The bulk of the Multics Communication System resides in the Multics 
Supervisor and in a separate machine, the Front-End Network Processor (FNP). 
There may be up to eight FNPs on a Multics system. The user-ring and supervisor 
portions of the Multics Communication System are principally concerned with 
terminal management, while the primary responsibility of the FNP is channel 
management. The determination of the number and types of channels to manage, 
however, comes in part from the physical configuration, and in part from a 
user-ring data base, the channel definition table (CDT). The CDT is maintained 
by the system administrator; its contents are described in Section 4. 


TERMINALS AND CHANNELS 


The term "channel" (or "communications channel"), as used in this manual, 
refers to the logical connection between the system and a remote input/output 
device via an FNP. This includes a physical connection, which may go through a 
telephone system or a private communications network, or may consist of one or 
more hardwired cables. Normally, there is a one-to-one correspondence between 
logical connections and physical connections, except in the case of multiplexed 
channels, described later in this section. . 


' The word "terminal" is used to refer to the device itself; it may be an 
ordinary interactive terminal, or it may be a computer controlling one or more 
peripheral devices. This manual is concerned primarily with channels and 
channel management; the use and control of terminals is described in the 
Programmer's Reference manual. 


rn NE | St 


An FNP is either a Datanet 6670 (model 6651, 6661, or 6678) or a Datanet 
6600 (modei 6632). (An eariier version of tne Datanet 6600, known as a Datanet 
355, can also be used). The type of FNP is specified in the CDT (as explained 
in Section 4) in order to account for minor software differences between the two 
machines, 
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Each FNP is connected to a Multics input/output multiplexer (I0OM) by means 
of a peripheral of the FNP called the direct interface adapter (DIA), and a DI 
channel in the IOM. A Datanet 6670 interfaces to communications channels through 
a device known as a high-speed multiline controller, or HMLC. A Datanet 6600 
interfaces to communications channels through devices called line adapters, which 
are of two types: a low-speed line adapter (LSLA) and a high-speed line adapter 
(HSLA). Each controller or adapter has subchannels to which the individual 
communications channels (sometimes called "“lines") are connected. 


{ HMLC Subchannels 


An HMLC handles synchronous channels at speeds ranging from 1,200 to 72,000 
baud, or asynchronous channels at speeds ranging from 110 to 19,200 baud. A 
Datanet 6670 can have up to 12 HMLCs, with each one capable of supporting up to 
eight subchannels (with a maximum combined speed of 72,000 baud). For compatibility, 
HMLCs are discussed in this manual in terms of HSLAs (the Datanet 6670 has no 
equivalent to the LSLA). Thus, four HMLCs are the equivalent of one HSLA, since 
an HSLA can support up to 32 subchannels (see below). 


LSLA Subchannels 


An LSLA handles asynchronous channels only, at speeds ranging from 110 to 
300 baud. Ech LSLA is logically divided into 52 "time slots"; a 
10-character-per-second (110 baud) subchannel takes up one time slot, a 
15-character-per-second (134.5 or 150 baud) subchannel takes up two time slots, 
and a 30-character-per-second (300 baud) subchannel takes up three time slots. 
Thus, each LSLA can have a maximum of seventeen 300-baud channels, or fifty-two 
110-baud channels, or some other number in between depending on the mix of 
speeds. A Datanet 6600 can have up to six LSLAs; a Datanet 6670 has no equivalent 
to the LSLA. 


HSLA Subchannels 


| An HSLA handles synchronous channels at speeds ranging from 1,200 to 72,000 

baud, or asynchronous channels at speeds ranging from 110 to 19,200 baud. A 
Datanet 6600 can have up to three HSLAs, with each one capable of supporting up 
to 32 independent subchannels (although memory constraints may limit the efficacy 
of such a configuration; see Appendix B). A Datanet 6670 can also have the 
equivalent of up to three HSLAs, or one for every four HMLCs. 


MULTIPLEXED CHANNELS 


The device associated with a physical channel may be some kind of concentrator 
that controls multiple terminals (examples of such concentrators include the 
Honeywell VIP 7700 series and the IBM Model 3270 series). For some types of 
concentrator, the Multics Communication System is capable of treating each terminal 
as a separate logical channel, if so instructed by the CDT. In this case, the 
channel occupied by the concentrator is called a multiplexed channel, and the 
concentrator is referred to as a multiplexer; the logical channels associated 
with the individual terminals are called subchannels of the multiplexer. The 
multiplexed channel and its subchannels must all be defined in the CDT. In 
theory, a subchannel of a multiplexer might itself be multiplexed. Such multiplexing 
can be carried to any number of levels. 
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Since an FNP controls many channels, but communicates with the central 
system over a single channel (the DIA), the FNP may be regarded as a multiplexer. 
In fact, as indicated in Section 5, the operator commands used to control multiplexers 
(load_mpx, start_mpx, etc.) are also used to control FNPs. Furthermore, frequent 
reference is made in this manual to a channel's multiplexer or "parent multiplexer" 
(i.e., the multiplexer of which it is a subchannel); when the channel referred 
to is a physical FNP channel, the parent multiplexer is the FNP. 


Appendix A contains detailed information on how to configure certain 
system-supplied multiplexers. 


CHANNEL NAMES 


Each communications channel has a unique name that identifies the FNP, 
controller or adapter, and subchannel through which it is connected. Subchannels 
of multiplexed channels are identified by additional components in their names. 
For example, “a.h102" identifies channel O02 of HSLA 71 on FNP a. The format of a 
channel name is described in detail in the Programmer's Reference manual. 


INITIALIZATION 


When the system comes up and the answering service is initialized, each FNP 
specified in the CDT is loaded (provided that a corresponding FNP ecard appears 
in the config deck, and that the CDT does not specify a service type of "inactive" 
for the FNP). If the FNP is successfully loaded, all the communications channels 
on that FNP are initialized. For nonmultiplexed channels, this means "listening" 
to the channel, i.e., putting it in a state in which dialups are possible. For 
multiplexed channels, initialization means setting up various internal data bases 
and initializing each subchannel of the multiplexer. 


DY 2 le rolexer hangs wo, ell She. subchannels. ere automatically Sune up, 
and the multiplexer (and its subchanneis) is reinitialized. Similarly, if an 
FNP crashes, it is automatically reloaded, and all its channels reinitialized. 
For information on how to control the loading and initialization of multiplexers 
(including FNPs), see Sections 5 and 6. 


CONSISTENCY OF CONFIGURATION 


In order for a channel or set of channels to be usable, the data bases 
describing the channel configuration must be consistent with each other, and 
with the physical configuration. In particular, the following points should be 
observed: 


e All channels must be represented in the channel definition tabie (CDT). 
Tf channels are missing from the CDT, they can he added and the CDT 
replaced as described in Sections 4 and 5; use of such added channels 
requires the reloading of a multiplexer, as described in Section 5. 
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The attributes and configuration of each channel as described in the 
CDT must agree with its actual characteristics; specifically, it must 
be cabled to the correct subchannel of the correct LSLA or HSLA, and 
the appropriate modems (if any) must be installed with the correct 
options (see Section 3 for more information about modems). If the CDT 
and the configuration disagree, either the CDT should be corrected (as 
indicated above) or the physical configuration should be adjusted to 
agree with the CDT. In the latter case, the multiplexer probably does 
not need to be reloaded; however, the channel may have to be reinitialized 
by using the attach and detach commands (see Section 5). 


Any FNP that is to be used must be represented by an FNP card in the 
BOS config deck, and must be cabled to the IOM channel specified on 
the FNP card. (The config deck is described in the MOH.) If the FNP 
ecard is specified incorrectly or is missing, the FNP is unusable until 
the next Multics bootload; the config deck has to be corrected from. 
BOS between bootloads. See the MOH for more information. 


Each FNP must also be represented by an entry in the CDT; the FNP core 
image specified in this entry must exist, and must support at least as 
many LSLAs and HSLAS as are specified in the CDT entry. If any channels 
on that FNP require special communications protocols (see Section 3), 
the FNP modules that implement those protocols must be included in the 
core image (see Section 6). If the core image and the CDT entry 
disagree, either the CDT should be replaced, or the core image should 
be recreated using the bind fnp command (described in Section toes In 
either case, the FNP must be reloaded before use. 


A site may implement its own communications protocol(s) and add its 
own FNP control tables module(s) to the core image. The line types 
ASYNC 1, ASYNC 2, ASYNC 3, SYNC 1, SYNC 2, and SYNC 3 are reserved for 
such site-defined protocols. For information on the preparation of 
control tables modules, see the Multics Communication System manual. 


All terminal types specified in the CDT, as well as any others that 
the site intends to support, must be represented by entries in the 
terminal type table (TTT). A standard TTT is supplied with the system; 
however, if the site has terminals other than those specified in the 
standard TTT, the system administrator may add entries for those terminals 
to the terminal type file (TTF) and replace the system TTT 
(>system_control_1>ttt). In certain cases, individual users may wish 
to define their own terminal types in a private TTT; for this reason, 
the TTF and TTT are described in the Programmer's Reference manual. 
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SECTION 2 


TERMINAL TYPES AND LINE TYPES 


CLASSIFICATION OF COMMUNICATIONS CHANNELS 


The Multics Communication System is designed to support a wide variety of 
communications protocols and devices. For this reason, it is necessary to identify 
the particular characteristics of each channel. This identification is accomplished 
by assigning a line type and a2 terminal type to each channel. 


A line type defines the communications protocol used by a channel. The 
following items are aspects of the line type: 


Synchronous or asynchronous transmission 
character size 

error detection and recovery 

message blocking 

message acknowledgement 

modem control 


©2006 9% 


Not all line types have all of the above aspects. Only synchronous line types, 
for example, are concerned with messages, which are blocks of continuously 
transmitted characters (see the discussion of synehronous protocols in Section 
aS 


ws * 


A terminal type defines the operating characteristics of a terminal. These 
characteristics include: 


character set (graphic symbols represented) 

character code (e.g., ASCII, EBCDIC, etc.) 

control sequences required to effect carriage movement 

and other special functions 

number of fill characters required for carriage movement functions 
terminal initialization sequence to clear screen, set tabs, etc. 
line length and page length 

character echoing modes 
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The terminal type concept permits the Multics Communication System to provide a 
uniform interface for terminal input/output. This eliminates the need to embed 
terminai-speeifie knowledge in most user and system software. 


ine) 
| 
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LINE TYPES 


The following standard line types are provided by the Multics Communication 
System: 


ASCII 
device similar to 7-bit ASCII using Bell 103-type modem protocol 
1050 
device similar to IBM Model 1050 
2741 
device similar to IBM Model 2741, with or without auto EOT inhibit 
ARDS 
device similar to Adage, Inc. Advanced Remote Display Station (ARDS) 
protocol using Bell 202S-type modem with reverse channel 
SYNC 
ASCII synchronous connections, no protocol 
G115 . 
ASCII synchronous connection, Model Level 6 remote computer interface 
(RCI) protocol 
BSC 


binary synchronous protocol 

202ETX 
device similar to GE TermiNet 1200 protocol using Bell 202S-type 
modem without reverse channel 

VIP 
device similar to Honeywell Model 7700 Visual Information Projection 
(VIP) system 

POLLED VIP 

“device similar to Honeywell Model 7760 VIP system 

X25LAP 
synchronous High-level Data Link Control (HDLC) X.25 protocol 
implementing frame level of CCITT recommendation of 1980. Used mainly 
to interface with a Value Added Network (VAN) such as TYMNET. 


It is possible for a site to create new line types not already provided by 
the Multics Communication System. Each such new line type requires the addition 
of a site-provided control tables module to the FNP software. This module must 
implement the desired communications protocol. Procedures for creating such 
modules are described in the Multics Communication System manual, Order No. AN85. 


Line Type Assignment 


The assignment of line types to channels is specified in the channel definition 
table (CDT). A complete description of the CDT is contained in Section 4 of 
this manual. The selection of a line type for a given channel must, of course, 
be consistent with the actual channel hardware. If no line type is specified 
for a channel, one of the several asynchronous line types is automatically selected. 
Therefore, line types shouid aiways be specified for synchronous channels. 


The line type of a channel can only be changed while the channel is not in 
use. Ordinary users cannot do this. In order to change a line type, an administrator 
must create a new CDT specifying a new line type for a particular channel. The 
new CDT must then be installed. The line has to be removed from the system 
using the operator command, detach, and reattached using the attach command. If 
the channel is not dialed up at this time, the new line type takes effect 
immediately. Otherwise, the new line type does not take effect until the current 
connection is terminated. 
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TERMINAL TYPES 


The terminal types provided by the Multics Communication System are defined 
in a segment called the terminal type table (TTT). This segment is generated 
from a source segment called the terminal type file (TTF). A complete 
description of the TTF and the TTT is contained in the Programmer's Reference 
manual. 


A standard version of the TTF is provided with each system release. It 
has the pathname >tools>TTF and is copied to >udd>sa>a at site initialization 
time. This TTF can be easily modified to add new terminal types or to change 
characteristics of existing terminal types. This allows each site to develop a 
customized TTF and TTT. 


Although most users ordinarily depend on the site-installed version of the 
-TTT, it is possible for any user to substitute his own private TTT. A user can 
create a TTT in exactly the same manner as a system administrator. This affords 
users the ability to define terminal types suited to their individual 
preferences. 


Terminal Type Assignment 


An initial terminal type is assigned to a login service channel at dialup 
time in one of several ways. An initial terminal type can be specified in the 
CDT. This is commonly done for dedicated channels which are always connected to 
the same terminal. If an initial terminal type is not specified in the CDT, 
then the default type table in the TTT is used to choose a terminal type based 
on line type and baud rate. In either case, an attempt is made to read an 
answerback (if allowed by the CDT) from the terminal. If the terminal responds, 
the answerback is decoded according to answerback specifications in the TTT 
which indicate initial terminal types. 


A terminal type for slave or autocall channels may be specified in the CDT. 
If this is done, then the terminal type and the default modes for the terminal 
are set and the initial string is sent at slave channel dialup time or when an 
autocall channel is connected. If a terminal type for slave or autocall 
channels is not specified in the CDT, then the above steps are not performed. 


The initial terminal type established by the system can be changed by the 
user. The terminal type (ttp) preaccess command can be used prior to login to 
alter the established terminal type, or the user can specify the -terminal type 
control argument to the login command to set the terminal type accordingly. 
After login, the user may invoke the set tty command to change his terminal 
type. The user may also change his TTT by use of the set ttt path command. 
Subsequent use of the set tty command will then reference the user-selected TTT. 
All of these commands are described in the Commands manual. 
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SECTION 2 


MODEMS .AND TERMINAL -CONNEGTIONS 


A terminal or concentrator can be connected to an HMLC (or HSLA or LSLA) in { 


any of several ways, depending on the line type and the available equipment. 
The path between the FNP and the terminal is often referred to as a "communications 
link." This section describes the general types of communications links that _ 
are possible, and includes a list of communications equipment that may be used 
to connect a device to a Multics system. 


TYPES OF COMMUNICATIONS LINKS 


Communications links can be categorized in a variety of ways. The following 
paragraphs discuss the most important distinctions among communications links, 
namely, whether they are: asynchronous or synchronous; full duplex or half 
duplex; hardwired, private-line, or dialup. 


Asynchronous/Synchronous 


An asynchronous link is one over which characters are erous mitted singly, 
at unpredictable intervals. The individual bits of each character are transmitted 
at a fixed rate (the bit rate or baud rate of the channel), Sut the time between 
characters is arbitrary. To allow the hardware to identify character boundaries, 
each character is preceded by a start bit and followed by one or two stop bits. 
Each character normally includes a parity bit, which is used to check whether 
the character has been received correctly. 


On a synchronous link, characters are transmitted in continuous blocks, and 
the time between blocks is arbitrary. One or more instances of a special bit 
pattern, called a synchronization character, is transmitted at the beginning of 
each block. Parity bits may or may not be included; some kind of checksum is 
generally appended to each block to ensure correct reception of the block. The 
blocks transmitted over a given link often must contain control information in 
some specified format; see the discussion under "Communications Protocols" below. 
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neentrators, etc., generally require a synchronous link. 


a1 CC75-01 


Full Duplex/Half Duplex 


A communications link is full duplex if data can be transmitted across it 
in either direction, or both directions, without changing the physical state of 
the link. It is half duplex if the connection permits transmission in only one 
direction at a time, and requires specific action to alter the direction of 
transmission (known as "turning the line around"). Because of the number of 
telephone wires required to implement the link, full duplex links are sometimes 

M called "4-wire", and half duplex links are called "2-wire." Asynchronous links 
are normally full duplex; synchronous links may be either full duplex or half 
duplex. 


Hardwired, Private Line, Dialup 


A hardwired link is one in which the terminal is connected directly to the 
FNP by means of an appropriately wired cable, i.e., a DC path. The length of 
the cable is normally limited to 50 feet, but can be longer, depending on speed, 
cable type, and hardware at each end. 


A private line is a link that utilizes a telephone-like transmission medium, 
and requires a modem at each end (see the discussion of modems below); however, 
the physical connection is reserved for use by the specific terminal-FNP link, 
and does not have to be reestablished for each use. The path may be furnished 
by the telephone company (an AC path), or be a long wire (a DC path). 


A dialup link uses a switched network, usually the public telephone system. 
Each such link must be established by dialing into the network at the start of a 
terminal session, and is closed by a hangup operation. Thus, while a hardwired 
or private-line channel appears to be dialed up immediately whenever a listen 
operation is performed by the system, a dialup channel is not available for use 
until a user has actually dialed the phone. 


Hardwired and private-line links are usually full duplex; dialup synchronous 
| links may be either half duplex or full duplex. 


It should be noted that when a channel with a login service type dials up, 
if no commands are entered within a reasonable time interval (normally two minutes) 
the answering service automatically hangs up the channel and listens to it again. 
This is not desirable on a hardwired or private-line channel, since another 
dialup signal follows immediately; therefore, the hardwired attribute in the CDT 
entry for the channel instructs the answering service to leave the channel dialed 
up until the channel starts being used. This is the only effect of the hardwired 
attribute in the CDT. (See the description of the channel master file in Section!4 


inf mati b is bs; : hin: 4 tet hice ‘ 
for more information about service types and channel attributes.) 


The private line keyword used in the dataset statement in the CMF indicates 
that the channel is a private-line link, and also that it is full duplex. The 
private line keyword is only interpreted if the dataset specified is "201C", 
Other datasets default to either private-line or dialup; see Table 3-1 (later in 
this section) for more information. 
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MODEMS 


A modem (modulator/demodulator) is a device that converts a digital signal 
(received and generated by computers and terminal equipment) to an analog signal 
(suitable for transmission across telephone lines) and vice versa. Acommunications 
link that is not hardwired requires two modems, one cabled to the FNP and one 
cabled to the terminal, with a telephone-system connection between the two modems. 
Dataset is a frequently used synonym for modem. 


There are many different types of modems: synchronous and asynchronous; 
with and without dialing capabilities. Some can run at a variety of speeds, and 
some are restricted to a specific speed. The modems currently most common are 
those manufactured by American Telephone & Telegraph. Modems made by other 
manufacturers are available, although they generally are approximate equivalents 
of Bell modems. A specific modem model may be obtained with a variety of options. 
In most cases, the options recommended by the manufacturer should be used, but a 
few exceptions are noted in Table 3-1. 


The two modems at the ends of a communications link must be either the same 
type or compatible types and have similar or compatible options. In a few 
cases, pairs of modems operate by having one member initiate the call (at the 
terminal end) and the other respond to it (at the FNP end); the Bell Model 113A/113B 
is an example of such a pair. 


Table 3-1 lists Bell modems currently usable on a Multics system, and indicates, 
for each one, the speed(s) at which it can run, whether or not it is synchronous 
or asynchronous, whether it is dialup or private-line or both, what specification 
Should be given in the dataset statement of the CMF, and any other important 
information. For more detailed information on a particular modem, refer to the 
modem's technical specification, which is available from the manufacturer. 


COMMUNICATIONS PROTOCOLS 


A communications protocol is a set of conventions observed by the two ends 
of a communications link in order to exchange data in an orderly and predictable 
fashion. The specification of a protocol may include conventions for controlling 
the physical state of the link, as well as the format and sequencing of blocks 
of data. Full duplex asynchronous links do not generally use protocols; half 
duplex asynchronous links uSually require fairly simple protocols to determine 
the direction of transmission at any given time. Synchronous links generally 
use more elaborate protocols to ensure that each block of data is received 
correctly and in correct sequence. 


The following are examples of asynchronous and synchronous protocols supported 
by the Multics Communications System, with the line types used to implement them 
(see Section 2 for a further discussion of line types). 


Examples of Asynchronous Protocols 


Protocol: ARDS with 202S modem with reverse channel option 
Line Type: ARDS 


Protocol: GE TermiNet 1200 with 2028S modem without reverse channel option 
Line Type: 202ETX 
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Modem Descriptions 


Table 3-1. 
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Examples of Synchronous Protocols 


Protocol: Level 6 RCI 
Line Type: G115 


Protocol: Binary synchronous (bisync) 
Tana Tuna. Recor 


eS +JyJrLe pw aL) 
Protocol: Honeywell polled VIP 
Line Type: POLLED VIP 


AUTOMATIC BAUD RATE DETECTION 


The autobaud feature of the Multics Communication System is designed to 
recognize/configure the baud rate (bits per second) of an asynchronous HMLC (or 
HSLA) channel at dialup time. The autobaud facility selects a 1200 baud rate if 
the high-speed indicator is on (pin!12, for most modem types); otherwise it 
selects a rate of 110, 133, 150, 300, or 1200 baud based on the sampling of bit 
changes for the incoming characters, "1", "L"™, "CR", 


Lead Control Selection Of 1200 Baud 


If the modem connected to the FNP turns "on" pin 12 of the cable connected 
from it to the FNP, the channel is set to 1200 baud and it is then handled in 
the normal manner. The FNP modem can be set to respond to a switch on the 
terminal modem which indicates that the terminal is operating at 1200 baud. The 
operation of the channel does not appear any different to the user than if a 
Strictly 1200 baud channel is dialed into (there is no requirement for the user 
to type any characters before the login banner is received). 


Bit Sampling Selects Other Bauds 
If the signal on pin 12 is "off", sampling for the bit changes of an input 
character is performed. To accomplish this, the following sequence occurs: 
V3 The user establishes a connection with the host. 
2. The user types in either the letter "1" or "L" or a carriage return. 
3. The software in the FNP scans the incoming bit stream looking for bit 
changes at 300 baud. Since the sample character is known ("1", "L", 
"CR"), the changes in state of the bits ("0" or "1") indicate the 


timing necessary to transmit the bits, and therefore the baud rate of 
the channel is determined. 
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y, The channel is then handled in the normal manner. The answerback is 
checked (if required), the initial string (if any) is sent and the 
login banner is displayed. , 


5. The user types in any of the preaccess commands (MAP, etc.) if desired. 
Bis The user logs into the system using "1" again for "login", enter, etc. 
Modems 


Any asynchronous HMLC channel may be configured with the autobaud feature. 
For dialup channels not using special modems, automatic baud rate detection is 
possible only up to 1200 baud. In this range, most modems and acoustic couplers 
are able to interface with host modems. 


There are several modems that can be used on channels configured with the 
autobaud feature which make use of the pin!12 lead change. Vadic (Model! 3467) 
and Western Electric (Model!212A) are two manufacturers that make such modems. 
Special encoding techniques are required to handle the 1200-baud full duplex 
data over voice-grade dialup lines. For this reason, a modem of one manufacturer 
may not necessarily be able to interface to a modem of another manufacturer. 
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CHANNEL MASTER FILE 


CHANNEL DEFINITION TABLE 


The channel definition table (CDT), a data base in the segment: 


>sel>edt 


describes the attributes of all Datanet Front-End Network Processors (FNPs) and 
communications channels on the system. Write access on this segment is necessary 
only for the initializer; read access is necessary for users of certain metering 
commands. 


The CDT is a binary table containing numbers and pointers as well as character 
Strings. Therefore, it cannot be examined or modified with standard editors. 
The display cdt command is used to print the contents of the whole CDT or selected 
entries. The reset cdt meters command resets the per channel count of dialups 
and total connect time. The tty lines command lists all channels and their 
counters. When the system administrator wishes to add or delete channels, or to 
change the information about a channel in its CDT entry, he modifies the channel 
master file (CMF), converts the CMF into a new copy of the CDT with the ev emf 
command, and uses the install command to signal the answering service to modify 
the system's copy of the CDT. Thus, the site management can make certain changes 
in the site's configuration of terminal channels without waiting for a system 


ahitdauwn 
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Each FNP and terminal channel in the system has a CDT entry. This includes 
not only channels used for logins, but also special terminal channels, such as 
channels used by the message coordinator for the I/O of the initializer and 
daemons, and channels describing remote stations operated by the I/O daemons. 
These channels have flags set in the CDT entry indicating the way they can be 
used. 


CHANNEL MASTER FILE 


The CMF describes all FNPs, multiplexers, and terminal channels on the 
system. It is an ASCIT file, normally stored in >udd>sa>a>CMF.cmf, that can be 
converted into a binary tahle, which is installed hy the answering service at 
the system administrator's request. 
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syntax of the CMF 


The CMF consists of a series of entries, one for each FNP or channel. Each 
entry consists of a series of statements that begin with a keyword and end with 
a semicolon. White space and PL/I-style comments enclosed by /* and ¥*/ may 
appear between any elements of the CMF. The last entry in the CMF must be the 
end statement. Global statements specifying defaults appear anywhere before the 
end statement; the defaults that they specify are in effect for all subsequent 
channel entries, until they are changed by subsequent global statements. Fxcept 
for the end statement, all statements consist of the statement keyword, a colon, 
the variable field of the statement, and a semicolon. 


The entry for each FNP consists of an FNP statement, followed by statements 
describing the attributes of the FNP. Attributes not specified for an FNP are 
set from defaults supplied by the cv_cmf program. 


The entry for each channel consists of a name statement naming the channel, 
which may be followed by statements describing the attributes of the channel. 
Attributes not specified for a channel are set from the defaults established by 
global statements or those supplied by the cv emf command. (See "CMF Default 
Statements" below.) Thus, a very simple CMF could consist of an FNP entry, a 
name statement for each channel, and an end statement, as follows: 


FNP: A; 
type: DN6670; 
memory: 64; 


hsla: : 
name: a.ho0o0o; 
name: a.h001; 
end; 


FNP ENTRIES IN THE CMF 


A description of each statement in an FNP entry of the CMF is given below. 


FNP: <name>; 
The FNP statement is required. It specifies the tag of the FNP being 
described. Up to eight FNPs may be specified. An FNP card with the same 
name is also required in the config deck. See the Programmer's Reference 
manual for restrictions on the name of an FNP. 


type: <FNP type); 
The type statement is optional. It specifies the type of the FNP, which 
may be either DN355, DN6600, or DN6670. DN355 and DN6600 are equivalent. 
The default is DN355. 


memory: <K-words>; 
The memory statement is optional. It specifies the size of the FNP memory 
in K (1024 words). Acceptable values are 32 through 256, in increments of 
32 (i.e., 32, 64, 96, 128, etc.) The default is 64. 


lsla: <number of lslas>; 
The lsla statement is optional. It specifies the number of LSLAs configured 
on this FNP (DN6600/DN355 only). The number may be zero through six; the 
default is zero. 


hsla: <number of hslas>; 


The hsla statement is optional. It specifies the number of HSLAs configured 
on this FNP. The number may be zero through three; the default is zero. 
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image: <path>; 


The image statement is optional. It specifies the pathname of the FNP core 
image to be used for this FNP. The default is >system_control_1>mes. Each 
FNP may have a different core image depending on its configuration and 
supported line types. The path argument should specify a segment that is 
on the root logical volume to ensure that the FNP can be reloaded without 
having to worry about demounted volumes. (The FNP cannot be reloaded if 
path is on a demounted volume.) 


service: <active or inactive>; 


The service statement is optional. If specified, the variable field must 


be either active or inactive... An. active FNP is loaded and used by the -- >> 


system. An inactive FNP is not automatically loaded. However, it can be 
loaded by operator command or made active by installation of a new CDT. 
(If an FNP is missing from the CMF at answering service startup time, 
rather than being included with a service type of inactive, it cannot be 
used during the current Multics bootload. The default is active. See 
"Changing Channel Configuration," below.) 


CHANNEL ENTRIES IN THE CMF 


A description of each statement in a channel entry of the CMF is given 


below. 


name: 


name: 


<channel name>; 
The name statement is required. It specifies a unique channel name for the 
channel and can be up to 32 characters long. FNP-type channel names are 
divided into components separated by periods, with each component 
representing a level of multiplexing. A complete description of channel 
naming conventions appears in the Programmer's Reference manual. 


<channel name 1>-<channel name 2); 
A pair of channel names can be given in the name statement. The first N 
characters of the two names must be identical, where N is that portion of 
the names up to the atetts representing the first and last subchannel 
numbers (the subchannel number in the second name must be greater than that 
in the first name). The effect of this form of the name statement is to 
specify a group of adjacent channels having identical characteristics. 
Their names are formed by starting with the first name, increasing the 
subchannel number by 1 to form each name, and ending with the second name. 
The number of channels in the group is equal to one plus the difference 
between the two subchannel numbers. 


For example: the name statement a.h100-a.h220 specifies a group of 
successive channel names, the first of which is a.h100, the second, a.h101, 
the third, a.h102, ete., up to a.h220. Likewise, the name statement 
b.h203.prt1-b.h203prt8 specifies a group of eight channel names, the first 
of which is b.h203.prt1, the second, b.h203prt2, the third, b.h203.prt3, 
etc., up to b.h203.prté8. 


generic destination: <"string">; 


. ta 7 a be EB ive Gees 
The generic destination statement is cpt appiies Oniy cto tne siave 


and autocall service types. The string may ‘be any site-specific value 
(e.g-, tymnet, modem, protocol _converter box) that does not resemble a 
channel name. If included in the CMF entry, the string is used to match 
the channel specifier used in a dial _out or privileged_attach operation. 
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baud: 


<baud_rate>; 
The baud statement is optional. It specifies the baud rate of the channel. 
The baud rate must be compatible with the FNP line adapter type and must be 
chosen from the following list: 


0 600 7200 
110 1200 9600 
133 1800 19200 
150 2400 40800 
300 4800 50000 

72000 


The channel is assumed synchronous only if a synchronous line type is also 
specified. Zero and none are equivalent and may only be used for network 
channels, which are not attached through an FNP. The auto keyword requests 
automatic baud rate detection at dialup time for HSLA channels (see the 
discussion of automatic baud rate detection in Section 3). Baud rates 
higher than 19200 are valid only for synchronous channels. 


NOTE: At speeds of 4800 baud and below, no more than 960 characters are 
sent to the FNP at a time. 


The baud rate of a synchronous’ channel is not controlled by software. The 
baud statement for a synchronous channel simply informs the system of the 
speed of the hardware connection. The correct baud rate should be 
specified, however, so that the system can choose the optimal buffer size 
for the given rate. 


attributes: <attr1, attr2, ... attrN>; 
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The attributes statement is optional. This statement applies only to login 
service channels. When this statement is used, the global attributes are 
overridden for this channel. If no attributes statement is specified, the 
global attributes are used. The * character is used to negate the 
specified attribute. The following attributes may be specified: 


audit, “audit 
if enabled, access errors on the channel are audited. 


check_acs, “~check_acs 
if enabled, access to the channel is controlled by the access 
control segment >sc1>rcep>CHANNEL-NAME.acs. For details on the 
ACS, see "Access Control Segments" in the MAM System. 


check answerback, “check_answerback 
if enabled, specifies that the answerback returned by the 
channel is to be checked against the one supplied in the 
answerback statement (see below). 


dont_read_answerback, “dont_read_answerback 
if enabled, specifies that no attempt is to be made to read the 
answerback of the channel. 


hardwired, “hardwired 
if enabled, specifies that the channel is directly wired, not 
connected through a switching system. 


none 
if enabled, specifies that all of the "*“" values of the 
attributes listed above are assigned. 


set_modes, “set_modes 
if enabled, specifies that the modes associated with the 
terminal type of the channel are to be set when the channel 
dials up. 
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access class: <"authorization">$; 


The access class statement is optional. If specified, it must be 


‘followed by a valid authorization string, enclosed in quotes. The 


specified authorization is the maximum authorization for any login 
over the channel. See the convert_authorization_ subroutine in the 
Subroutines for an explanation of valid authorization strings. 


answerback: <string>; 


The answerback statement is optional. This statement applies only to 
login service channels. If specified, it must have as a variable 
field a four-character string that is the expected answerback for the 
channel... The star’ convention. is allowed.....If the. value..is.null, then...... 
no answerback check is made. Otherwise, the answerback code from the 


terminal is matched with the specified field; if they disagree, a 
message is printed to the user and to the operator, and the channel is 
hung up. 


terminal type: <terminal type>; 
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The terminal _ type statement is optional. If specified, its variable 
field must contain one of the terminal types defined in the terminal 
type table (described in the Programmer's Reference manual); specified 
terminal types are checked against the current TTT when the CDT is 
installed. 


The names of the possible terminal types can be ascertained by using 
the print_terminal_ types command (described in the Commands manual). 
These names may be entered in uppercase or lowercase. The terminal 
type specified is set before any input or output is done to the 
terminal; thus, this statement overrides the default terminal type 
(which is based on the line type and baud rate). For example, ifa 
site has some IBM Model 2741s that are EBCDIC and some that are 
Correspondence, the terminal _ type statement may be used to determine 
whether the greeting message is printed in EBCDIC or Correspondence. 
The terminal type statement does not force the terminal to remain the 
same type; it merely specifies the initial type. Thus, the answerback 
identifier, the -terminal type login control argument, and process 
requests may override the terminal type statement. 


<line type>, <attri>, <attr2>; | 
The line type statement is optional. If specified, its line type 
field must contain one of the following line types: 
none unspecified (select protocol at dialup time) 
ASCII terminals: ASCII, TN300, TTY33, TTY37, TTY38 
1050 terminal: 1050 
2741 terminals: 2741, CORR2741 
ARDS 202S with ARDS line turnaround (reverse channel) 
Syne synchronous line, no protocol 
6415 remote computer interface, synchronous (GRTS) 
BSC binary synchronous communications 
202ETX 202S with ETX line turnaround (no reverse channel) 
VIP Honeywell VIP 7700, single station 
POLLED VIP Honeywell VIP 7760 
X25LAP _ HDLC X.25 frame level 
ASYNC1 
ASYNC2 optional site-defined asynchronous line types 
ASYNC3 
SYNC1 
SYNC2 optional site-defined synchronous line types 
SYNC3 
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dataset: 


charge: 


service: 
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The line type specified is passed to the terminal control software 
before the channel is enabled for listening, in order to set the line 
protocol to be used for handling communications on the channel. If no 
line type statement is specified, the terminal control software is 
capable of determining (for LSLA and asynchronous HSLA channels) 
whether the protocol used should be one of: 


2741 133 baud default 
1050 133 baud alternate, if answerback indicates 
ASCII default for all other speeds 


If an ARDS terminal is to be used, a line type statement must be 
specified (i.e., line type: ARDS;). 


<name>, <attrod; 

The dataset statement is optional. It identifies the generic type of 
dataset/modem being used on the channel. If specified, the name field 
must be chosen from the following list of Bell modem names, although 
any modem that is similar may be used. 


103A 208A 

201C 2088 

202C5 209A 
202C6 


The attribute may be private line to indicate that the modem is being 
used on a 4-wire circuit (see Section 3 for more information). 


<chargename or noned; 


The charge statement is optional. If specified, its variable field 
must contain a charge name listed in the device prices array in the 
installation_parms segment (see Section 4 in the MAM System), or be 
"none." The charge type selects the per-hour surcharge for use of the 
channel. 


<service type>; 
The service statement is optional. If specified, its variable field 
must be one of the following service types: 


login 

me 

Slave 
autocall 
inactive 
multiplexer 


The service type determines whether the channel can be used for normal 


logins or is under control of some special software. The slave 
service is used only for special channels attached by the I/0 daemons 
for bulk ata input/output or other special subsystems. The mec 


service is specified for all message coordinator channels. The 
autocall service indicates that the channel is used to dial out using 
an automatic call unit. The inactive service indicates that the 
channel exists but is currently not to be used. A channel installed 
as inactive can be changed only through installation of a new CDT. A 
channel rendered inactive because of an error condition or operator 
command (remove) can be changed either through the operator attach 
command or installation of a new CDT. The multiplexer service type is 
used for a multiplexer channel (see the discussion of multiplexers in 
Section 1). If aoservice type of multiplexer is specified, the 
multiplexer_type statement (see below) must be provided. 


Access Control Segments (ACSs) specify access to the slave and 
autocall lines. Access to login lines may be similarly 
controlled--see the description of the attributes statement above. 
See also "Access Control Segments" in the MAM System. 


A service type of slave must be specified for every channel that an 
I/O daemon driver directly attaches, and the names of such channels 
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must be specified in the I/O0 daemon tables, >ddd>idd>iod tables. 
Channels that are to be dialed to a daemon driver must be given a 
service type of login in the CMF, and dial identifiers must be 
specified in the I/0 daemon tables. (In order to use a particular 
registered dial identifier, a user must have rw access’ to the ACS. 
See Section 7, “Registered Dial Identifier," in the MAM System for 
more information.) 


The default service type is login--meaning that the normal logins are 
allowed. 


multiplexer type: <type>, <active or inactive>; 

The multiplexer type statement is required for channels with a service 
type of multiplexer and is invalid for other channels. If it is 
specified, the variable field must be ibm3270, vip7760, hasp, sty, or 
X25. It indicates the type of multiplexer to be connected to the 
channel. The multiplexer is initialized as soon as its parent 
multiplexer initializes if this statement includes the active key. 
The multiplexer is not initialized until the load_mpx operator command 
is used if this statement includes the inactive key. The default is 
active. 


comment: <"string">; 

The comment statement is optional. If its variable field contains any 
blanks or punctuation, it must be enclosed in quotes. The variable 
field is saved in the CDT entry (up to 48 characters). The comment 
field may be used to identify the modem and telephone line connected 
to a channel. The comment is printed by the tty lines command and by 
various answering-service programs that print error messages about the 
channel. 


initial_command: <"initializer request">; 
The initial_command statement is optional. This statement applies 
only to login service channels. If it is specified, the variable 
field must be a valid initializer command (e.g., login, dial) line, 
enelosed in quotes. Whenever the channel dials up, the initial 
command is executed before the first line is read from the terminal. 


CMF Default Statements 


Control statements that begin with a capital letter are global statements. 
Global statements exist for each of the statements that specify attributes. If 
no global statements are given in a CMF, the following set of defaults is 
assumed: 


Attributes: none; 
Access_class: system low; 
Answerback: anal s 
Baud: 300; 
Generic destination: ""; 
Line_ type: none}; 
Terminal type: none3 
Charge: none; 
Service: logins 
Comment: ws 
Initial command: on 
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GLOBAL STATEMENTS APPLICABLE TO ALL FNPS 


The following additional global statements are used to set system-wide 
parameters: 


FNP _required_up time: <number of minutes>; 
The FNP_required_up_ time statement is optional. It sets the minimum 
acceptable time between failures for all FNPs. If an FNP crashes after 
being up for less than the specified number of minutes, twice in 
succession, then it is not reloaded automatically. The default is five 
minutes. A value of zero disables automatic reloading of FNPs. 


Spare channel count: <number of spare channels>; 

The Spare _channel_ count statement is optional. It specifies the number of 
channels the site expects to add to the CMF between system initializations 
(without rebooting Multics). In other words, if Spare_channel_count is 20, 
and the CDT in use at system initialization time specifies 100 channels, no 
more than 120 channels can be configured during that session. The LCT 
(logical channel table) is allocated in tty_buf with the number of entries 
equal to the number of channels in the CDT plus the number specified in 
this statement. An FNP initialization error occurs if the number of new 
channels being added exceeds the spare channel count and an FNP load occurs 
before the system is reinitialized. The default is 10. 


Changing Channel Configuration 


The channel configuration and the characteristics of existing channels can 
be changed at any time by installing a CDT containing the new information. 
Section 5 describes the procedures for making these changes and discusses their 
implications. 


The parameters that are changed at the next Multics bootload are actually 
set during answering service initialization, when either the startup or multics 
command is given. If necessary, changes to these parameters can be made by 
copying a new CDT into >scl in the initializer process in admin mode, before the 
answering service is started. However, use of this method to replace the CDT 
destroys the channel usage statistics kept in the CDT entries. The preferred 
way to make a channel configuration change take effect immediately is to issue 
the initializer command, multics, and then with the initializer process in admin 
mode, modify the CMF, compile it, install the CDT using the install command 
(which preserves channel usage statistics), and then shut down and reboot 
Multics. 


SAMPLE CHANNEL MASTER FILE 


/* Sample Channel Master File */ 


Service: login; 

Charge: none3 

Terminal type: none; 

Line type: none; 

Attributes: none; 

Baud: 300; 

Access class: "system_high"; 
FNP_required_up_time: 2; 


FNP: As 
type: DN6670; 
memory: 64; 
hsla: 13 
image: mcs; 
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name: a-h000; 
baud: 9600; 
terminal type: VIP7801; 


attrributes: hardwired, dont_read_answerback; 


initial command: "modes echoplex, *tabs,tabecho,crecho,lfecho"; 


comment: "1200 baud, hsla 0, subchn 0"; 


/*temporarily disconnected, so comment it out: 


name: a.h001; 
baud: 1200; 
charge: caa;3 
terminal type: ASCII; 


commént:—"1200 baud, hsla 0, subchn 1, x319, vadic"; 


end comment out */ 


name: a.h002; 
baud: auto; 


comment: "auto baud, hsla 0, subchn 2, x316"; 


name: a.h0033 


comment: "300 baud, hsla 0, subchn 3, x324"; 


Baud: 4800; 
name: a.h012; 
service: slave; 
line type: BSC; 
dataset: 208A; 
comment: "hsla 0, subchn 12, BSC"; 


name: a.h0133 
service: slave; 
line type: BSC; 
dataset: 208A; 
comment: "hsla 0, subchn 13, BSC"; 


name: a.h014; 
baud: 4800; 
line type: BSC; 
service: multiplexer; 


multiplexer type: hasp3 


atUaAw. rve 


terminal type: IMFT_HASP WORKSTATION; 


comment: "HASP multiplexer used for file transfer"; 


name: a.h014.opr; 
service: slave; 


comment: "IMFT HASP daemon - operator control stream."s; 


name: a.h014.rdri-a.h014.rdr8; 
service: slave; 
comment:"IMFT HASP daemon I/O stream."; 


name: a.h014.punt-a.n014.pun4; 
service: slave; 
comment:"IMFT HASP daemon I/O stream."3 


name: a.hO14.prti-a.n014.prt4; 
service: slave; 
comment:"IMFT HASP daemon I/0 stream."3 


name: a.eh0173 
charge: caa;3 
terminal type: ASCIT; 
attributes: hardwired; 
comment: "4800 baud, hsla 0, subchn 17, 


name: a.h018; 
baud: 1200; 
charge: caa3 


4-9 


hw Delta 4000"; 
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terminal _ type: ASCII; 


comment: "1200 baud, hsla 0, subchn 1, 


name: a.h020; 
baud: 2400; 
service: multiplexer; 
multiplexer type x25; 
line type: X25LAP; 
terminal type: X25 TYMNET; 


comment: "TYMNET voice-grade HDLC X25 link."; 


name: a.h020.001-a.h020.028; 
initial command: echo; 


comment: "TYMNET X.25 login subchannels"; 


name: a.h020.029-a.h020. 032; 


service: autocall; 
line type: X25LAP; 


comment: "TYMNET X.25 autocall subchannels.";3 


name: a.h030; 
line_type: POLLED VIP; 
baud: 4800; 
service: multiplexer; 
multiplexer type: vip7760; 


comment: "4800 VIP7760 polled controller"; 


terminal_type: VIP7760 CONTROLLER; 


name: a.h030.d015 
terminal _type: VIP7760; 
comment: "Station 01 on polled VIP"; 


name: a.h030.d02;5 
terminal type: VIP7760; 
comment: "Station 02 on polled VIP"; 


end; 
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MODIFYING COMMUNICATIONS CHANNELS 


This section describes the recommended procedures for modifying the 
configuration of communications channels on the Multics system. In particular, 
it describes the procedures used to add a channel, delete a channel, or change 
the characteristics or status of an existing channel. 


In general, one or two major steps are involved in modifying the channel 
configuration. The first step is changing the CDT, which can be done in any 
sufficiently privileged process, as follows: 


1. Use a text editor to make the necessary changes to the CMF; 
2. Use the ev_ emf command to create a CDT from the new CMF (in >udd>Ssad>da) 


3% Use the install command to install the new CDT. 


The syntax of the CMF is described in Section 4, the cv emf command is 
described in Section 7, and the install command is described in MAM System. 


The second major step, which is not necessary in all cases, is reloading 
(or reinitializing) the multiplexer of which the channel being changed is a 
subchannel. In the case of physical channels, of course, this is an FNP (see 
the discussion of multiplexers and subchannels in Section 1). This is done by 
means of the load mpx initializer command, described in the MOH, and requires 
the use of the operator's console, a terminal dialed to the initializer, or the 
send admin command command (described in the MAM System). It is suggested that 
the -check control argument to the load mpx command be used to obtain information 
about possible inconsistencies in the configuration. 


Loading a multiplexer while one or more of its channels is in use is not 
recommended unless all such users are warned and given a chance to log out. In 
any case, the load mpx command, unless given the -force control argument, refuses 
to proceed if anyof the multiplexer's channels are inuse. The stop mbx initializer 
command can be used to prevent any idle channels from being dialed up to a 
multiplexer scheduled for reloading. 


ADDING CHANNELS 


To add a channel to the system, simply add the description of the channel 
to the CMF, compile and install the new CDT, and, when appropriate, reload the 
immediately superior multiplexer (e.g., if adding channel a.h007, reload FNP a). 
Once this has been done, and the appropriate physical connection has been made, 
the channel is ready for use. Note that the reloading of the multiplexer is not 
necessary if the channel was configured the last time the multiplexer was loaded; 
i.e., if two new CDTs have been installed since the last load of the multiplexer, 
one deleting the channel and the other restoring it, the channel is then ready 
for immediate use without reloading the multiplexer. 
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DELETING CHANNELS 


To delete a channel from the system, delete (edit) its entry from the CMF, 
and compile and install tke new CDT. If the channel is in use at the time, the 
installation of the CDT causes it to be hung up and any associated user process 
to be destroyed. The channel is then made unusable. Note that the multiplexer 
does not have to be reloaded to accomplish this effect; in fact, if it becomes 
desirable to restore the channel later, this can be done simply by adding it to 
the CDT as described above, provided that the multiplexer has not been reloaded 
in the meantime. 


CHANGING THE STATUS OF A CHANNEL 


ee ee ee 


It may be desirable at various times to change the status or characteristics 
of one or more channels in any of Several ways. Changes in the physical configuration 
may necessitate changing the line type, baud rate, or other attributes of a 
channel; the site may wish to change the way a channel is used by changing its 
service type; or it may be necessary to make a channel temporarily unusable. 
These changes can be effected by changes to the CDT and/or the use of initializer 
commands; some of them, to take effect, require reloading of a multiplexer. The 
most common types of changes, and the procedures used to accomplish them, are 
described below. 


Changing Channel Attributes 


In general, it is possible to change those attributes of a channel that are 
specified in the CMF by modifying the CMF entry and compiling and installing the 
new CDT. The changes thus specified do not, in general, take effect immediately 
on a channel that is already dialed up, but rather are saved until some change 
occurs in the state of the channel. The change of state may actually take 
effect at the next hangup, the next dialup, or the next load of the multiplexer. 
Table 5-1 shows, for various channel attributes, when a change in the attribute 
takes effect, depending on whether the channel is currently in use. Some attributes 
should never be changed on an active channel: the access class attribute (shown 
below in Table 5-1) and those entries in Table 5-2 that say "immediate" or 
"remove". 


Attaching, Detaching, and Removing Channels 


et eee 


The initializer commands attach, detach, and remove (described in the MOH) 
are used to change the state of a channel as perceived by the system. The 
following peragraphs describe their effects and the circumstances under which 
they should be used. 


attach 


The attach command puts a previously inactive channel into a state where it 
can accept dialups. The channel might be inactive as the result of a detach or 
remove command (see below), or through some error condition which rendered it 
inactive. However, a channel defined at CDT installation time with a service 
type of inactive can be placed in another state only through a subsequent CDT 
installation. 
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Table 5-1. Changing Channel Attributes 


Attribute Channel in Use Channel Not in Use 

access class dialup (see Note below) immediately 

baud multiplexer load multiplexer load 

answerback | — dialup dialup 

line type | hangup immediately 

dataset multiplexer load multiplexer load 

terminal type dialup dialup 

initial command dialup dialup 

charge dialup dialup 

set_modes dialup dialup 

audit dialup dialup 

hardwired hangup dialup 

check answerback dialup dialup 

dont_read_answerback dialup dialup 

multiplexer _type multipiexer load multiplexer load 
NOTE: If the new access class is lower than the authorization of the process 

uSing the channel, the process is bumped. 


detach 


The detach command renders a channel unusable until it is reattached or its 
multiplexer is reloaded. It can be used to disable a channel temporarily. Ifa 
user is logged in over the channel, the user is bumped as a result of the detach 
command. 


remove 


The remove command has the same effect as the detach command. The princinal 
difference is that it forcibly hangs up the channel and detaches it from any 
user process, whereas the detach command bumps the user by signalling the answering 
service. The remove command can thus be used in cases when the channel or its 
associated data bases are in an inconsistent state, and a detach or bump operation 
has failed to complete properly. Certain changes in service type cause a channel 
to be automatically removed, as explained below. A removed channel, like a 
detached one, is restored by the attach command, or when the multiplexer is next 
loaded. 
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SERVICE TYPES 


If achannel presently being used or available for one type of service 
(e.g., user login) is to be changed to a different type (e.g., autocall), its 
CMF entry must be modified and a new CDT compiled and installed. The change of 
service type may not take effect immediately, particularly if the channel is in 
use. In some cases, the change does not take effect until either the 
multiplexer is reloaded or the channel is detached and attached; in other cases, 
the installation of the CDT automatically removes the channel, and the new 
service type goes into effect only when it is reattached. Table 5-2 shows, for 
each combination of old and new service type, when the change actually takes 
effect. A notation of "attach" indicates that the channel must be detached and 
reattached; a notation of "remove" indicates that the channel is automatically 
removed, and must be attached (by operator command, or a_ subsequent CDT 
installation or answering service startup) before it can be used with its new 
service type. Reloading a multiplexer implicitly attaches all of its 
subchannels whose service types are not "inactive." 


Table 5-2. Changing Service Types 


Service j; i i 1 \ 

Ty pe 1 { 1 i 
Old\New { login MC slave autocall imultiplexeri inactive 
login | -- remove | remove ihangup(1) | remove(2) | remove ! 
MC attach | -- | attach | attach : attach(2) | hangup(1)} 
slave | immediate attach 3 -- | immediate remove(2) | hangup(1)} 
autocall {hangup(1) | remove ! remove | -- remove(2) ! remove | 
multiplexer | remove | remove | remove i remove 7 -- | remove ! 
inactive | immediate attach attach | immediate attach(2) ! -- 3 
i i t 1 1 


(1) If the channel is not dialed up, the change takes effect immediately. 


(2) The multiplexer channel cannot be used until its parent multiplexer 
(generally an FNP) is reloaded. 
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FNP AND MULTIPLEXER CONFIGURATION 


Multiplexers (including FNPs) can be added, deleted, and have their states 
changed in ways somewhat analogous to those described above for ordinary channels. 
Adding a multiplexer is like adding any other channel; the channel does not 
become usable until its parent multiplexer is loaded. In the case of an FNP, 
there must be a corresponding FNP card in the config deck (see the description 
of the config deck in the MOH). In other words, if a new CDT is installed with 
an additional FNP, and no corresponding FNP card appears in the config deck, 
that FNP cannot be loaded. , 


Deleting a multiplexer channel implicitly deletes all its subchannels. (In 
fact, a CMF specifying subchannels of an undefined multiplexer channel is in 
error and cannot be compiled). Changing the service type of an existing 
non-multiplexed channel to "multiplexer" is equivalent to adding a new multiplexer 
channel. As indicated in Table 5-2, such a channel is generally removed when 
the new CDT is installed, and cannot be used as a multiplexer until its parent 
multiplexer is next loaded. 


The stop mpx initializer command (described in the MOH) causes the multiplexer 
to refuse to accept dialups on its subchannels without affecting any subchannels 
that are already dialed up. It can be used while the multiplexer is running or 
before loading it; in the latter case, the multiplexer can be initialized without 
accepting dialups from any subchannels. In either case, the effect of the stop mpx 
command can be reversed by using the start mpx command. - 


If a multiplexer disconnects (or, in the case of an FNP, crashes), all its 
subchannels are automatically hung up. They are not listened to again until the 
multiplexer is reloaded (if any of the subchannels is itself a multiplexer, the 
hangup is of course propagated to its subchannels, and so on). The reload is 
usually performed automatically by the initializer. If, however, a multiplexer 
crashes repeatedly in a short interval (namely, the number of minutes specified 
for the FNP required up time statement in the CMF), a message such as: 


FNP a is in apparent crash loop and will not be reloaded 
is printed at the initializer terminal, and automatic reloading is discontinued. 
At this point, it is advisable to consult the programming staff. Once whatever 


is wrong has been fixed, the multiplexer can be reloaded manually using the 
load _mpx command. 
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FNP Crash Notification 


It is possible to set up at a given installation an exec _com to be invoked 
automatically whenever the FNP crashes, which informs the appropriate personnel 
of the subsequent automatic dump. The exec _com might: 

* send mail as notification of the existence of the dump 

& automatically format and dprint the dump 

e automatically backup to an older core image 

The administrator creates an exec _com named fnp crash notify.ec in the 
directory >scl. The exec com may contain, for example: 

&command line off 


sm Prog sm [string "FNP" &1 "crashed at" [date time] "running" &2] 


Then, after an FNP dump is taken, the answering service looks for the 
existence of >sc1>fnp crash notify.ec. If this segment is found, it is invoked 
as follows: = ~ 


ec fnp_crash notify fnp tag core image path dump path 


There is no default exec com; each installation must prepare its own. 
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SECTION 6 


FNP CORE IMAGES 


Programs that run in the FNP are loaded from a "core image" that resides in 
the Multics storage hierarchy. The pathname of this core image is specified in 
the CDT, as explained in Section 4. 


MODIFYING FNP CORE IMAGES 


It may be desirable, on occasion, to modify this core image in order to 
make use of improvements or bug fixes to the software; to add a module in order 
to run a new line type; to delete unneeded programs in order to make more buffer 
Space available in the FNP; or to change the maximum number of LSLAS or HSLAs 
that may be configured. Any such change does not take effect until the FNP is 
next loaded. 


The system administrator does not usually have to change the contents of an 
FNP module; if he does, however, he should edit the source segment, which is 
named MCDULE.map255, where MODULE is the name of the module. The map355 command 
(described in Section 7) is then used to produce an object segment named MODULE.objdk, 
which is used in the next step (binding). Before binding can be performed, 
however, object segments in the FNP that are unchanged must be extracted from 
the object archive (see the MPM Commands) into a directory in the search list 


(the default is the working directory). 


In order to prepare a new core image, the bind fnp command must be used. 
If the configuration of HSLAs or LSLAs is being changed, memory size is being 
changed, or modules are being added or deleted, the bindfile must be modified. 
The bindfile is a segment named IMAGE.bind fnp, where IMAGE is the name of the 
core image to be generated (usually "mes"). The output of the bind fnp command 
is a core image segment named IMAGE. The bind fnp command is described in 
Section 7. v 


USING FNP CORE IMAGE 


To make use of tne ccre image tnusS créated, e1tner copy it to the place in 
the storage hierarchy described by the image pathname in the CDT, or change the 
specification of the core image pathname in the CMF, convert it, and install the 
resulting CDT. The next time the FNP is loaded (either automatically or by 


means of the load mpx operator command), the new core image is used. 
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REQUIRED MODULES 


The Multics Communication System requires that a number of modules be present 
in the FNP core image. These modules form the basic software to support the 
activities of the channels attached to the FNP. The modules are: 


control tables 
dia man 
interpreter 
scheduler 
utilities 

init 


Note that the init module is required in the core image but that after it is 
finished initializing, its space in the FNP memory is released for use as input 
or output buffers. 


OPTIONAL MODULES 


All other modules are optionally configured depending on site requirements. 
Some of these modules are required because of the line type statement in the 
CMF. The following table indicates which module is required in the core image 
when a channel is configured on an FNP with a line type in the CMF: 


line type in CMF FNP module 


ASCII control tables 
1050 control tables 
2741 control tables 
ARDS ards tables 
Syne control tables 
G115 g115 tables 
BSC bse _ tables 
2O02ETX t202 tables 
VIP vip tables 
POLLED VIP polled vip tables 
X25LAP_ x25 tables 


The autobaud tables module is required when the baud rate of a channel is 
specified as "auto". 


The lsla man module need only be present if the number of LSLAs is not 
zero. This module should not be configured in the core image for a DN6670 FNP. 
if the isia man module is not configured, the module keyword (along with the 
type and size keywords) describing the lsla_man module must not be in the bindfile. 


The hsla man module is an optional module for DN355 or DN6600 FNP types if 
HSLA hardware is configured. This module must be in the bindfile for a DN6670 
FNP. If the hsla man module is not configured, the module, type and size keywords 
describing this module must not be in the bindfile. 
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The trace module is optional and if left out, the module keyword with its 
size and mask must also be removed. 


The acu_tables module is required in the FNP core image if one of its 
channels has the service type of "autocall" in the CDT. 


The hasp tables module is required with bse tables if a HASP multiplexer 
channel is configured on the FNP. The line type of this channel is BSC in the 
CDT, causing bse tables to take control of the channel when the FNP is told to 
listen to it. As the HASP multiplexer is loading, it notifies bsc_ tables to use 
hasp tables to help with the line protocol, ~ —_—  -«: . 


The breakpoint_man module is only required if the system maintenance 
personnel want to set breakpoints in a control tables module. This mechanism is 
only defined to operate on code that is interpreted by the interpreter module 
and constructed of op blocks. See the Multics Communications System manual for 
more details. 7 


The ibm3270 tables module is required with the bsc_tables module to service 
a channel using IBM3270 protocol. The line type of this channel is BSC in the 
CDT causing bsc_tables to take control of the channel when the FNP is told to 
listen to it. The ibm3270 I/0 module in the control system indicates to 
bse tables through a line control order that it is to use the ibm3270_ tables to 
help with the line protocol. Refer to the Subroutines manual for further 
information. 


The console man module is only required if the console keyword parameter is 
yes. 


The meters module is required if the meter keyword parameter is yes or 
omitted. 


The printer trace modu 


le jie 
DN355 or DN6632 with a printer 
DN6670. 


The ic sampler module is only required if the ic sample request to the 
debug _fnp command is to be used. Refer to the debug fnp command description in 
the Multics Communications System manual for further information. 


There is no macros module. The macros.map355 is the source that creates 
the 355 macros library that is used by the map355 command to assemble all the 
modules that execute in the FNP. The macros.map355 source is also used in 
creating a data base utilized by the debug fnp command to reference values in 
the FNP by name rather than by absolute location. 


A GCOS job named macros asm is used to produce the 355 macros library. If 
it is necessary to generate anew macro library, this job should be run in a 
working directory that contains the macros.map355 source, using a command of the 
form: 


gcos >ldd>mcs>info>macros asm -truncate {other -control args} 
where other -control args may include, for example, -list and -lower case to 


produce an ASCII list segment. Refer to the Multics GCOS Environment Simulator 
manual, Order No. ANO5, for more information. 
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The gicb module is kept separate in a suitable form for loading into the 
FNP in the directory >system_library_unbundled. This is the first executable 
code loaded into the FNP which loads the core image into the FNP. For further 
information, refer to the Multics Communications System manual. 


THE BINDFILE 


The bindfile is a segment containing symbolic instructions that control the 
operation of the bind _fnp command. Its entryname ends with a suffix of bind fnp. 


The symbolic instructions of the bindfile have their own syntax that allows 
for statements consisting of a keyword followed by zero or more parameters, and 
ending with a statement delimiter. Each keyword designates a certain action to 
be undertaken by the bind_fnp command pertaining to parameters following the 
keyword. 


Following is a list of the delimiters used: 


keyword delimiter. It is used to identify a keyword followed by 
one or more parameters. A keyword that is followed by no parameters 
is delimited by a statement delimiter. 


statement delimiter. 


we 


‘ parameter delimiter (the last parameter is delimited by a statement 
delimiter). 


/* begin comment. 


®/ end comment. 


Bindfile Key Words 


hsla 
the parameter is the maximum number of high speed line adapters (HSLA) 
that this core image supports. 


lsla 
the parameter is the maximum number of low speed line adapters (LSLA) 
that this core image supports. 


memory 
the parameter is the amount of memory available on the FNP expressed 
in units of 1024 18-bit words. 


console 
the parameter can be: 
yes console can be configured. 
no console cannot be configured. 


printer 
the parameter can be: 
yes printer can be configured 
£ n 


es 
Am nrointor f2eeaeretes he 42ne FS eis 
no printer cannot be configured. 
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meter 
the parameter can be: 
yes metering is enabled. 
no metering is disabled. 


order 
the parameters are a list of FNP object segments in the order they are 
to be loaded. The suffix objdk is assumed for all object segments 


The last segment specified must be init. 


entry ae 23 : 2 ie Peete 
the parameter specifies the name of the entry at which execution is to 
begin after the segment is loaded into the FNP. Unless the site is 
using a changed version of the init module, the entry must be istart. 


version 
the parameter is a string of up to four characters that is stored in 
the core image as its version identifier. This string is printed when 
the FNP is loaded, and is also printed by the tty meters command. 


module 
the parameter specifies the name of the FNP object segment that will 
be described by the following keywords. 


type 
the parameter specifies the type of FNP object segment. It can be one 
of the following: hsla, 1sla or trace. 
size 
the parameter is the number of 18-bit words required for table space. 
The use of the size statement depends on the type specified for this 
module. If the type is trace, then size represents the size of the 
trace table. If the type is hsla or lsla, then the size represents 
the size of each HSLA table (or LSLA table). If a site is configuring 
less than the maximum number of LSLAsS or HSLAs, the bind fnp command 
will remove unused table space from the end of the module. 
mask 
the parameter is a 6-digit octal number that specifies the modules to 
be traced. Only the six high-order bits (two digits) of this number 
are interpreted; each bit corresponds to one module. If the bit is 
"1"b, the corresponding module is traced. The correspondence between 
bits and modules is as follows: 
it octal representation module 
0 NHOXXXX scheduler 
1 2O0XXXX dia_man 
2 10XXXX interpreter 
3 O4XXXX utilities 
4 O2XXXX lsla_man 
e O1XXXX hsla_man 
This keyword can only be used if a trace type was also specified. 
end; 


specifies the end of information to be processed from the bindfile. 
It must be present at the end of the bindfile. 
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Sample bind fnp File 
/* Bindfile for Multics Communications System */ 


/* FNP configuration info */ 


version: 5.0; 
hsla: 38 
lsla: 0; 
memory: 64; 
console: no; 
meter: yes; 


printer: no; 


/* module load list */ 


order: scheduler, 
interpreter, 
control tables, 
dia man, 
hsla man, 
utilities, 
meters, 
trace, 
init; 


/*® entry to init from bootload */ 


entry: istart; 


/* table size specifications */ 


module: hsla_man; 
type: hsla; 
size: 973 
module: trace; 
type: trace; 
mask: 310000; /* trace enable mask */ 
size: Sle. 
end; 
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SECTION 7 


COMMANDS 


This section contains descriptions of commands useful for channel 
management and site communications administration. 


The conventions shown in the usage lines of these commands are the same as 
those used throughout the set of Multics manuals; briefly, arguments enclosed in 
braces ({}) are optional, and all others are required (unless otherwise noted). 


For a complete description of all the usage line conventions, refer to Section 1 
of the Commands manual. 


12/83 7-1 CC75-01B 


bind fnp bind _fnp 


Name: bind fnp 


The bind _fnp command produces a core image segment that can be loaded into 
the FNP. It uses two control segments: abindfile, which specifies the configuration 
that the FNP will support, the names and ordering of the object segments included 
in the core image, and the size of certain software tables; and an optional 
search rules segment, which specifies which directories are searched to find the 
object segments. 


Usage 


bind_fnp pathname {-control_args} 


where: 

1. pathname 
specifies the pathname of the bindfiie. If pathname does not have a 
suffix of bind_fnp, one is assumed. 

ca control args 


may be chosen from the following: 


-cross ref, -cref 
adds a symbol cross reference to the listing segment. If -cross ref 
is specified, the listing is generated regardless of whether -list 
is also specified. 


-list, -ls 
produces a listing segment whose name is derived from the name of 
the bindfile, with the suffix changed to list. The listing segment 
is a record of the binding. It contains a copy of the bindfile, a 
load map, and any error messages generated during binding. 


-search, -se 
indicates that the user wishes to specify the rules used to search 
for Multics Communications System object segments being bound into 
the core image. If given, there must be a segment in the working 
directory containing an ASCII list of relative pathnames of directories 
to be searched in the order in which the search is desired. By 
default, the working directory is searched. This segment must have 
the same entryname as the bindfile, but with the suffix changed to 


search. 


-version STR 
assigns a version of STR to the core image. The maximum length of 
STR is four characters. If this control argument is given, it overrides 
the version keyword specified in the bindfile. 
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bind fnp bind fnp 


Notes 


A default bindfile is supplied with the system. In general, the only fields 
that a site administrator would change aré: hsla, lsla, version, order, and the 
Size keyword for the trace module. 


When creating a new FNP core image, object segments that are unchanged must 
be extracted from the object archive (see the MPM Commands) into a directory in 
the search list before executing the bind fnp command. 


The syntax of the bindfile is described in Section 6. 
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Name: ghannel comm meters 


The channel comm meters command prints out metering information for a 
specified communications channel or channels. 


Usage 
channel comm _meters channel name {-control args} 


where: 


1. channel name 
Is the name of the channel for which information is to be printed. 
If it is the name of an FNP, totals for that FNP are reported. If 
channel name is a starname, information for every channel matching 
the starname is printed. 


Ze control args 
can be chosen from the following: 


-brief, -bf 
causes a reduced amount of information to be printed for each specified 
channel. 


-error 
causes only those meters to be printed that reflect error conditions. 


-Sinece bootload, -boot 
prints the meters accumulated since each channel's parent multiplexer 
(or, in the case of an FNP, the system) was last loaded. This 
control argument is incompatible with -since dialup (below). 


-Since dialup, -dial 
prints the meters accumulated since the channel last dialed up. This 
is the default. This control argument is incompatible with 
-Since bootload (above). 


-Summary, -Sum 
causes a one-line summary to be printed for each specified channel. 
This control argument may not be specified if either ~-brief or -error 
is specified. 


Notes 


If a single channel is specified, the caller must either be the current 
user of the specified channel or have access to either the metering gate gate 
or the phes gate. If a starname is specified, the user must have access fo one 
of the above-named gates. 


If -brief and -error are both specified, then only those error indications 
that would be printed with -brief are printed. See the example below. 
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Examples 


In the example below, code characters appear at the beginning of some lines; | 


these “charactérs do not appéar in the actual output of the command. The 
interpretation of the characters is as follows: 


-- this line appears for asynchronous channels only 
this line appears for synchronous channels only 
-- this line is among those printed if -brief is specified 
-- this line is among those printed if -error is specified 


MwWn eS 
' 
| 


Only lines marked with both B and E are printed if -brief and -error are both 
Specified. 

channel _ comm meters a.h000 

Total metering time 01:45:13 

a .h00O 
[The following meters are printed for all nonmultiplexed channels: ] 


-. before conversion after conversion ratio 


B Total characters input 984 935 0.95 
B Total characters output 10,540 11, 400 1.09 
B Average length of input ees &.3 
B Average length of output 63.3.1 69.4 
read write control total 
Number of calls 175 194 53 422 
Average time per call (msec.) 2.3 5.8 Ley 4.1 
Average chars. processed per call 5.6 56.1 
Number of software interrupts 113 
Average time per interrupt (msec.) 1.6 
B Effective speed (bps) 1.6 17.5 


[The following meters are printed for physical FNP channels only] 


input output 
SB Messages transmitted 240 224 
SB Minimum message length 5 12 
SB Maximum message length 143 508 
SB Average message length 10.3 57.6 
SBE Invalid input messages 6 (2.5% of total) 
SBE Output messages retransmitted 8 (1.6% of total) 


SBE Timeout waiting for acknowledge 2 (0.4% of output messages) 


Output overlaps in FNP 127 
Average length of DIA request queue 1.7 entries 


Pre-exhaust status 12 
Exhaust status 

Software transfer timing errors 
Bell/quits 

Echo buffer overflows 

Parity errors 


PP PP 
Pm mo 4 
ANWON 
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channel comm meters channel comm meters 


Avg. number of pending status events 1 
Software status queue overflows 1 
Hardware status queue overflows 6) 
Input buffer allocation failures 1 


-9 


3 077 07) 


[The following meters are printed for an entire FNP] 


FNP has been up for 04:15:12 
B Number of channels configured 88 
B Average number dialed up 43.7 
B FNP idle 74.9% 
B Idle at peak load &.0% 
input output 
B Characters transmitted 71,966,400 94,934,400 
B Characters per second 4,700 6,200 
E Abnormal DIA status events 3 
E Memory EDAC errors 0 
B Memory size 64K 
B Total available buffer pool 6,360 words 
B Avg. amount of free space 21,876 words 
B Average % of buffer pool available 34.7 
BE Buffer allocation failures 12 
E Output restricted by space ey 
Number of interrupts from this FNP 1,964, 208 
Avg. time/interrupt (ms) 3.1 
% of total CPU time 1.1 
Mailbox transactions: 
Input data 220, 349 
Output data 543,210 
Input control 14,111 
Output control 23,456 
Total 801,126 
bela inbound mailboxes in use 1.1 
verage outbound mailboxes in use 3.1 
Maximum outbound mailboxes in use 16 
E No outbound mailbox available 37 
E Input rejects 22 
E % of input transactions rejected 0.01 


The following example shows the format of the output of the command when 
the -summary control argument is specified. 


channel comm meters a.h00O* -summary 


cps epsi epso iotxXsbepQqa err ABE name user 
120 0.2 5.4 xX b Q 12 aB a.hoood Coren 

600 2-1 102.1 t X a 73 = Ss a.h005 ABClone 
30 9 Pos 2.6 e 2 aE a.hoog Parrish 
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channel comm meters 


The column headings are interpreted as follows: 


eps 


epsi 


epso 


channel comm meters 


the nominal speed of the ehannel, in characters per second. 


the effective speed of input over the channel, in characters per second. 


the effective speed of output over the channel, in characters per 


second. 


The following flags are printed if the corresponding condition has occurred 
at least once on the channel. 


i -- 


O ~- 


name 


user 


invalid input message 

output message retransmitted 
timeout waiting for acknowledge 
pre-exhaust status 

exhaust status 

software transfer timing error 
bell/quit 


echo buffer overflow 


software status queue overflow 
hardware status queue overflow 
input buffer allocation failure 


the total number of errors of all kinds 


: 
channel. 


that have occurred on the 


"a" for an asynchronous channel or "s" for a synchronous channel. 


the channel is in breakall mode. 


the channel is in echoplex mode. 


the name of the channel. 


the Personid of the current user of the channel. If the channel is 
not in use, or the user's name is not available, this field is left 


blank. 
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Name: console report 


The console report command creates and displays metering of terminal usage 
on the system baSed on the information obtained form the answering service logs. 


Usage 
console report {as log paths} {-control args} 


where: 


1. as_log paths 
are pathnames of answering service logs. The pathnames can be absolute 
or relative. 


2% control args 
ean be chosen from the following: 


-print 
causes a display of the metering on user output. 


-report reset, -rr 
causes a display of the metering on user output and resets the metering 
in the data base. 


-reset, -rs 
resets the metering in the data base. 


-sort 
sorts the data base alphanumerically by terminal answerback identifiers. 


Notes 


Control arguments and pathnames can appear anywhere in the command line. 
They are processed from left to right, one at a time. 


The header in the display produced when the -print and -report reset controi 
arguments are used is obtained from the system titles. This header may be too 
wide for the user's terminal and the user may wish to use the file output command. 


The command creates and stores data into two segments, termseg and termuSeg, 
in the current working directory when pathnames of answering-service logs are 
Specified. These segments are the data bases that the command expects to find 
in the current working directory when any of the control arguments are used. 
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console report 


Example 


Multics terminal usage 


Period from 08/26/80 1407.9 to 09/25/80 1600.2 


Type Count Logins 
2741 247 28 
TN300 395 622 
Daemon 101 873 
ASCII 1077 9563 
TELNET 13 0 
LA36 93 60 
VT100 HY 419 
LA120 5 112 
ID Type Location Logins 
User 
002 ASCII 1 
Derek.Multics 1 
Cou ASCII 2 
Aulin.Multics 2 
4HO5 LA120 73 
MKane. Network 38 
Marcus. Network 8 
Inada. Network 11 
SBWeber .Network 9 
Ducot.FlexMan 5 
Yip.Network 1 
Feinstein.Network | 
4Q> ASCII 2 
Stanzel.ARCS 1 
AWhite.ARCS 1 
40> VT100 2 
HSPP-BASIC. Student 1 
Soley.ARCS 1 
etc. 
where: 
Ts Type 
is the terminal type. 
2. Count 


3. Logins 


is the number of different terminals of 


are the number of completed logins. 


Nologins 


Lee 
48 

4 
1423 
324 
11 
45 

9 


Nologins 


26 


CPU Connect 
0:05 25.22 
18:47 604: 128 
38:08 4H56:06 
5371:45 7954: 30 
0:00 0:00 
0: 34 15:40 
6:10 367:53 
2:24 89:51 
CPU Connect 
0:04 3:03 
0:04 3:03 
0:01 L216 
0:01 1:16 
0: 46 75:54 
0:31 53:07 
0:04 6:09 
0:07 Sepa: 
0:05 6:37 
0:01 3343 
0:01 0:02 
0:01 0:27 
0:01 0:26 
0:01 0:03 
0:01 0:24 
0:01 0: 38 
0:01 0:16 
0:01 0:23 
that type. 


console report 
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console report console report 


Nologins 
the number of logins attempted and not completed. 


CPU 
is the amount of CPU time used. 
Connect 
is the amount of time actually logged in. 
ID 
is an identification number assigned to a specific terminal. 
Type User 
the terminal type and ID is shown on a heading, followed by a line 
for each user of the terminal giving usage statistics. 
Location 


is not used. 
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Name: ev_emf 


The ev emf command converts an ASCII channel master file (CMF) into a binary 
channel definition table (CDT). The binary table can be installed using the 
install command. . 


Usage 


ev_emf emf path {-control args} 
where: 


Nis emf path 
= is the pathname of the channel master file. If path does not have a 
suffix of emf, one is assumed. However, the suffix emf must be the 
last component of the name of the source segment. 


2. control args 
may be one of the following: 


~brief, -bf 
uses short form of error messages. 


-long, -lg 
uses long form of error messages. 


-severity N, -sv N 
causes error messages whose severity is less than N (where N is 0, 
1, 2, 3, or 4) not to be written to the user output switch. If this 


control argument is not specified, a severity level of 0 is assumed 
(i.e., all error messages are written to the user output switch). 


Notes 


If no control arguments are given, each error message is printed in long 
form the first time it occurs and in short form thereafter. 


The converted channel master file is given a name corresponding to the 
entryname of the source segment, with the emf suffix replaced by cdt. It is 
placed in the working directory. 
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ev emf ev emf 


| Notes on Severity Values 


The cv_cmf command associates the following severity values to be used by 
the severity active function: 


Value Meaning 
0 No compilation yet or no error. 
1 Warning. 
2 Correctable error. 
3 Fatal error. 
4 Unrecoverable error. 
5 Could not find source. 
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Name: display cdt 


The display cdt command enables a qualified user to display the contents of 
a channel definition table (CDT). 


Usage 


display _cdt {channel} {-control_ args} 


where: 

ale channel 
is the name of the communications channel for which the CDT entry is 
to be displayed. The star convention is allowed. 

Zs control args 


may be chosen from the following: 


-all, -a 
displays names and CDT indices for all channels in the CDT. 


-brief, -bf 
displays only channel names and CDT indices (without channel or FNP 
details). This is the default for the -all and -subtree control 
arguments. 


-emf path 
creates a CMF in the segment named path in a form suitable to cv emf, 
based on the contents of the CDT. - 


-header, -he 
displays the CDT header variables in addition to other requested 
information. 


-long, -lg 
displays detailed information for the specified channel or FNP. This 
is the default unless -all or -subtree is specified, in which case 
-brief is the default. 


-no header, -nhe 
™~ suppresses display of the CDT header variables. This is the default. 


-pathname path, -pn path 
displays the CDT whose pathname is path. By default, the CDT in the 
segment >sc1>cdt is displayed. 


-~Ssubtree 


displays the names and CDT indices for all subchannels (if any) of 
the specified channel. 
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display cdt display _cdt 


awe wUw 


If display edt is specified with no channel name and no control arguments, 
a usage error notification is returned. Specifying channel name only, with no 
control arguments, results in a -long display. 


The display cdt command enables the user to check for inconsistencies in a 
CDT before unnecessarily undertaking corrective action. 


The user must have r access to the CDT to invoke the display cdt command. 


Example 


To display the entire system CDT, specify: 
display edt -all -header 

To display the system CDT entry for channel a.1000 only, specify: 
display cdt a.1000 

To display all the subchannels of multiplexer a.h026.1, specify: 


display cdt a.h026.1 -subtree -long 
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Name: display fnp idle 


The display fnp idle command is used to display information on FNP idle 
time stored by the meter fnp idle command. The display can be in the form of a 
summary or a line graph (Chistogram). 


Usage 


display fnp idle {fnp names} {-control-args} 
where: 


1. fnp names 
i are the names of the FNPs for which idle time information is to be 
displayed. If fnp names is not specified, the display covers all 
FNPs for which information has been stored. 


2. control-args 
may be chosen from the following: 


-directory path, -dr path 
specifies that information is to be taken from segments in the directory 
with pathname path (see the meter fnp idle command description for | 
idle time segment specifications). The default is to display 
information from idle time segments in the working directory. 


-from DT, -fm DT 
specifies that the display is to cover a period beginning no earlier 
than the date/time DT, which must be in a form suitable for input to 
the convert date to binary subroutine. The default is to start the 
display from the most recent idle time segment. 


-histogram, -hist 
causes output in the form of a histogram, where a line shows the 
busy percentage for each FNP at a given time interval. The -histogram 
and -summary control arguments are mutually exclusive, but one or 
the other must be specified. 


-interval N 
specifies that each line in the histogram represents an N minute 
interval. This control argument is ignored if -summary is specified. 
The default is 15 minute intervals. 


-line length N, -11 N 
Specifies the line length of the histogram as N columns (N cannot be 
less than 38). This control argument is ignored if -summary is 
Specified. The default is the user's terminal line length (or 80 if 
output is directed to a file). 
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-summary, -Sum 
requests a summary display of FNP idle information for the specified 
time period. The -summary and -histogram control arguments are mutually 
exclusive, but one or the other must be specified. 


-to DT 
specifies that the display is to cover a period ending no later than 
the date/time DT, which must be in a form suitable for input to the 
convert date to binary subroutine. The default is to end the display 
with the latest available information. 


Examples 


The following command and resultant display represent a sample display fnp idle 
Summary request in which FNP "a" was found to be 90.3% idle for the Specified 
period (i.e., starting from the beginning of the most recent idle time segment 
and including the latest available information). Note that the busiest interval 
within the period is identified. 


display fnp idle a -summary 


FNP A idle from 01/04/82 0600. to 01/06/82 1436.: 90.27 
Busiest sample interval: 
01/05/82 1423. to 1424.: 43.7% idle 


The following command and resultant display represent a sample display fnp idle 
histogram request for all FNPs for which idle time has been recorded. The time 
period starts no earlier than noon on 01/06/82 and includes the latest available 
information. The busy percentage for each FNP is given at 10-minute intervals. 


display fnp idle -from "01/06/82 1200." -hist -interval 10 


01/06/82 1330. A B C 
1340. A Cc B 
1350. A CB 
B 
C 


fbusy C 10 20 30 40 50 60 
1 t ' 
I 


1400. A 

1410. A 

1420. A B. 3 

1430. A B C 
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Name: fnp throughput 


The fnp throughput command reports character throughput for an FNP or all 
FNPs and optionally allows the resetting of the metering interval. 


Usage 


fnp_throughput {fnp_id} {-control arg} 
where: 


1. fnp id 
es is the name of an FNP or "*", which means all currently running 
FNPs. This argument must be specified unless the -reset control 
argument is specified, in which case fnp id must not be specified. 


2. control arg 
“may be either, but not both, of the following. If neither is specified, 
information is printed and the metering interval is not reset. 


~report reset, rr 
causes statistics to be printed and the metering interval to be 
reset. If this control argument is specified, fnp id must be specified. 


-reset, -rs 
causes the metering interval to be reset without printing any statistics. 
If this control argument is specified, fnp id must be omitted. 


Notes 


The start of the metering interval in effect is measured from the time the 
FNP was last booted, or from the time the interval was last reset, whichever was 
the most recent event. 


The reset action of the -report reset control argument applies to the metering 
interval for all FNPs, even though the command invocation is specifie to the 
Statistics for a particular FNP. 
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Example 

To report on throughput statistics for FNP "a", while resetting the metering 
interval, specify: 

fnp throughput a -report reset 


The output would appear as follows: 


input output 
Characters transmitted 71,966, 400 94,934,400 
Characters per second 4,700 6,200 
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Name: map355 


The map355 command is used to assemble a program written in the FNP assembler 
language, map355. The command does not assemble the program directly. Instead, 
it prepares a GCOS job deck to perform the assembly and calls the GCOS Environment 
Simulator to do the work. 


Usage 


map355 pathname {-control args} 


where: 

1. pathname 
is the pathname of the source program to be assembled. The suffix 
of map355 need not be given by the user; it is assumed. 

ae control args 


may be chosen from the following: 


“li St, -<1s 
creates a listing segment that documents the compilation. The listing 
is created in the working directory, and has a suffix of list. 


-macro file path 
specifies the pathname of the macro file to be used for the assembly. 
If omitted, >1ldd>comm>fnp>info>355 macros is used. 


-check 
specifies that the compiler only perform a syntax check of the source. 
No object segment is created. 


-comdk 
creates a GCOS comdk segment. This segment contains a BCD version 
of the source program. It is created in the working directory with 
a suffix of comdk. 


-gcos list, -gceis 
Creates a GCOS listing segment in the working directory. This is a 
BCD version of the listing segment. It has a suffix of glist. 


-noconvert 
specifies that the input segment is a GCOS comdk, rather than an 
ASCII segment. If this control argument is used, the source segment 
must have a suffix of comdk. 


-argument list, -ag list 


specifies a list of arguments to be passed to the GCOS Environment 
Simulator. 
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This command creates a series of segments for use by the GCCS simulator. 
Somé are créated in the working directory, some are created in the process 
directory, and some through links in the working directory to the precess directory. 
These segments and links are normally deleted when the command terminates, leaving 
just the object segment, which has a suffix of objdk. 


Refer to the GCOS Environment Simulator manual, Order No. ANC5, for more 
information on the use of the GCOS Environment Simulator. 


Warning 


The map355 commend creates links in the working directory to segments to be 
placed in the process directory. If the process terminates in the middle of a 
compilation (new proc or a crash), these links will remain. This means that the 
next time the command is invoked, it will fail because the links point to a 
nonexistent directory. Even though the command fails, the bad links will be 
unlinked and subsequent invocations will work correctly. 


Severity 


The map255 command sets the following severity values to be returned by the- 
severity active function when the "map255" keyword is used: 


Value Meaning 
0 No error (or command not yet used) 
1 The assembly produced warning flags 
2 The objdk segment couid not be created 
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Name: mcs version 


The mes version command prints the version of the core image most recently 
loaded into the specified FNP. 


Usage 
mes version {fnp tag} 


Syntax as an Active Function 
[mes version {fnp tag}] 


where fnp tag is the identifier of the FNP whose version is to be printed. It 
can be a, b,c, d, €, ff, 2, or nN. If it is omitted, a is assumed, 
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Name: meter fnp idle 


The meter fnp idle command reads FNP idle metering information at specified 
intervals and stores the information in a segment for later viewing through the 
display fnp_idle command. 


Usage 


meter fnp_idle fnp name {-control-args} 
where: 


1. fnp name 
~ identifies the FNP for which idle time is to be recorded. 


2. controli-args may be chosen from the following: 


-directory path, -dr path 
specifies tnat the segments in which idle time information is to be 
Stored are to be created in the directory with pathname path. The 
default is the user's working directory. Segment names are of the 
form fnp idie data.F.MMDDYY.HHMMSS.I where Fis fnp name, MMDDYY.HHMMSS 
is the Starting date and time cf recording, and I is the specified 
interval in minutes. 


-interval N 
specifies that metering information is to be sampled every N minutes. 
The default is 1. 


-stop, -Sp 
terminates meter reading on this FNP. No other control argument may 
be specified with -stop. 


Notes 


Information is appended to the idle time segment until the -stop control 
argument is encountered or the process terminates. Maximum length of an idle 
time segment is 64K (to avoid exhausting a 256K ASTE). If a segment becomes 
full, a new one is created. On average, taking readings at one-minute intervals 
would fill a 64K segment in a little over three weeks (if a single process in 
which the cemmand was invoked were to run that long). 


Each invocation cf the command creates a new segment. 


Use of this command requires access ¢cither to the metering gate gate or the 
phes” gate. 
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Example 


The eommand 
meter fnp idle a -interval 5 


ereates a segment in the working directory into which will be stored idle time 
meter readings taken on FNP "a" at five-minute intervals. 


7-21 CC75-01 


set_x25_packet_threshold set_x25 packet_threshold 


Name: set x25 packet threshold 


The set_x25 packet threshold command sets the minimum size of X.25 "long" 
packets. Packets of this size or larger are given lower priority than short 
packets. 


Usage 
set_x25_ packet threshold channel name packet size 


where: 


1. channel name 
is the name of an X.25 multiplexer channel. 


2. packet size 
is the minimum length of a long packet, in characters. 


Notes 


If packet size is set larger than the maximum packet size in use by the 
multiplexer, no packets are given preferential treatment on the basis of size. 
The initial value of the minimum long packet size is determined by the 
"packet threshold" parameter in the terminal type definition for the 
multiplexer. The present value of the parameter, and the maximum size for all 
packets, is ineluded in the output from the tty dump command. 


Use of this command requires access to the hphes_ gate. 
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Name; system_comm_meters 


The system comm meters command prints out 


Bo metering information 
zero Multics Communications Management. 


Usage 
system_comm_meters {-control_args} 


where: 
1. control args 
can be chosen from the following: 


-reset, -rs 
resets the metering interval for the invoking process 
interval begins at the last call with -reset 
metering information is not printed. 


sO 


specified. 
If -reset has never been given 


system_comm_ meters 


for ring 


that the 
The 


in a process the interval begins at system initialization time. 


-report reset, -rr 


prints metering information and then resets the metering interval. 


Notes 


Use of the system_comm_meters command requires access to the meteri 
and phes_ gates. 


Example 
The following is a sample of the output of the system_comm_meters c 


Total metering time 05:43:27 


THROUGH PUT 

before conversion after conversion ratio 
Total characters input 17,234,567 15,543,210 0.90 
Total characters output 168,012, 345 185,876,543 1.14 


Average length of input 
Average length of output 
Input characters preconverted 


12.3 characters 
59.7 characters 
20,435 (1.2% of total) 


read write 
Number of calls 1,456,789 26,357,924 
Average time per call 6.37 msec. 9.63 msec. 
Average chars. processed 13.5 57.8 
Average chars. per msec. 2.1 5.8 
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CHANNEL INTERRUPTS 


system comm meters 


input output other total 

software "interrupts" 678, 901 423,440 110,011 1,212, 352 
average time (msec.) 1.34 0.56 0.23 1.01 
TTY BUF SPACE MANAGEMENT 
Total size of buffer pool 11,480 words 
Number of channels configured 143 
Number of multiplexed channels 8 
% of buffer pool in use current average 

input 6.9 6.5 

output 13.4 15.6 

control structures 15.8 15.3 

total 36.1 37.4 
Smallest amount of free space ever 4,258 words (38% of buffer pool) 

allocate free total 

Number of calls 24,657,988 20, 665, 443 45, 323,431 
Average time per call (msec.) 0.23 On 37 0.29 
% of total CPU 0.14 0.17 0.31 


Calls requiring loop on tty buf lock 
Average time spent looping on lock 
Number of allocation failures 


CHANNEL LOCK CONTENTION 

Number of calls to tty lock 

Times channel lock found locked 
Average time spent waiting for lock 
Maximum time spent waiting for lock 
Number of interrupts queued because 
channel locked 


ECHO NEGOTIATION 


Average time of transaction 
Number of characters echoed by supervisor 
Number of characters echoed by FNPs 


ABNORMAL EVENTS 


Input restarts 

Output restarts 

Output space overflows 
"needs space" calls 


1,249,340 (2.83% of total) 
0.14 msec. (0.01% of total CPU) 
9) (0.00% of attempts) 


2 
4,758 (5% of attempts) 
m 


25,437 (2.2% of interrupts) 


3.2 msec. 
21,576 (0.13% of input chars) 
335,466 (1.87% of input chars) 


12,576 (0.8% of read calls) 
304,289 (1.2% of write calls) 
16, 384 (0.1% of write calls) 
@ 
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Name: tty dump 


The tty dump command displays on the user's terminal the contents of the 
ring zero data bases describing either the current state of selected communications 
channels managed by the Multics Communication System or the state of such channels 
at the time of a system crash. See the Multics Communication System manual, 
Order No. AN&5, for more detailed information. 


Usage 


tty dump channel name {-control args} 


where: 

1s channel name 
Specifies the communications channels for which the state is to be 
displayed. The star convention is allowed (e.g., b.h202.**). This 
argument is incompatible with the -user control argument. 

2. -control args 


can be any of the following: 


-user STR 

specifies that the state of all communications channels attached by 
the specified user(s) is to be displayed. STR is a starname used to 
identify the users and is matched against the Person id.Project id 
of each logged in user. For example, "*Smith.M*" would match any 
user whose Person id ends with "Smith" that is logged in on a project 
that starts with "M"., This control argument is incompatible with 
the channel name argument and the -erf control argument. 


-erf N 
specifies that information about the channels is to be taken from 
the system dump associated with error report form (ERF) N located in 
>dumps. If this control argument is omitted, information about the 
currently running system is displayed. This control argument is 
incompatible with the -user control argument. 


-all, -a 
Specifies that, for each channel selected by the above arguments, 
information is to be displayed from the data bases of the channel, 
its parent multiplexer, its grandparent multiplexer, etc., up to the 
top level multiplexer channel. For example, for b.h202.prt1, all 
information from the data bases of b.h202.prt1, b.h202, and b that 
is related to b.h202.prt1 would be displayed. 


-lete 
specifies that the logical channel table entries (LTE) for the selected 
channels are to be displayed in addition to the other information 
normally displayed. If -all is specified, the LCTEs of all parent 
multiplexers are also displayed. 


-subchan, -sbe 
specifies that information from the data base 


of the parent multiplexer 
related only to the selected channels is to he di 
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specifies that the contents of any input and output buffers for the 
channels are to be displayed. This is the default. 


-brief, bf 
Suppresses display of the buffer contents. Only the addresses, size, 
and flags for each buffer are displayed. 


-ascii 
specifies that the contents of buffers are to be interpreted as 
ASCII characters in addition to being displayed as octal or hexadecimal 
values. 


~ebcdic8 
specifies that the contents of buffers are to be interpreted as 
EBCDIC (&-bit byte) characters in addition to being displayed as 
octal or hexadecimal values. 


-ebedic 9 
specifies that the contents of buffers are to be interpreted as 
EBCDIC (9-bit byte) characters, in addition to being displayed as 
octal or hexadecimal values. 


-octal 
specifies that the contents of buffers are to be displayed as octal 
values in addition to any character interpretation. Octal is the 
default numeric mode for buffer contents display. 


~hex8 
specifies that the contents of buffers are to be displayed as hexadecimal 
values, in addition to any character interpretation. Each &-bit 
byte in a word is displayed (nine hexadecimal digits). 


-hex9 
specifies that the contents of buffers are to be displayed as hexadecimal 
values, in addition to any character interpretation. The low order 
8 bits of each 9-bit byte in a word is displayed as two hexadecimal 
digits. 


Notes 


Use of the tty dump command without the -erf control argument requires 
access to the gate phes . 


The deseription of -the. dimer sesment. conmand in “the MPM Comnands srovides 
detailed information on the various buffer display formats. 


The default mode for buffer displays is to display their contents as octal 
values without any character interpretation. 


There are two sets of conflicting control arguments in tty dump: three 
with which to specify the base of numeric display (-octal, -hex8, and ~-hex9), 
and three with which to specify character code interpretation (-ascii, -ebcdic8, 
and -ebedic9). If conflicting control arguments are given on the command line, 
the last one specified will be used. 
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Examples 


The command line: 
tty dump b.h202.%* -all 
displays the state of multiplexer b.h202 and its subchannels. Displayed information 
includes the WTCBs/TCBs of the subchannels, multiplexer-specifie data for the 
subchannels, global data for the multiplexer, and the PCB of the multiplexer's 
physical FNP channel. 
By comparison, the command line: 


tty dump b.h202 -all 


displays only global multiplexer data and the PCB. 


7-26 CC75-01 


tty lines tty_lines 


Name: tty lines 


The tty lines command prints information about communications channels defined 
in the channel definition table (CDT). An optional argument can be used to 
print information about a subset of channels. 


Usage 
tty lines {arg} 


where arg is either a channel name, in which case information about the specified 
channel is printed, or one of the following: 


id STR 
prints information about channels on which the terminal most recently 
dialed up has an identification code specified by STR. The string 
STR is four characters long. 


diN 
prints information about each channel that has been dialed up N 
times or more. 

d=N : 
prints information about each channel that has been dialed up exactly 
N times. 

StN 
prints information about each channel whose current state code is N 
(see item 4 in "Notes" below). 

acN 
prints information about each channel whose activity code is N (see 
item 6 in "Notes" below). 

s1N 
prints information about the Nth entry in the CDT. 

-type STR 
prints information about each channel on which the most recently 
dialed terminal was of the terminal type specified by STR. 

Notes 


If the tty lines command is given with no argument, it prints information 
about all channels in the CDT. 
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tty lines 


For each channel, a line is printed in the following format: 


NAME TYPE DS W A BAUD Person id Project _id (ID) C 


where: 


1. 


a« 


NAME 


TYPE 


BAUD 


is the channel name, e.g., a.10064. 


is the terminal type that has most recently dialed the channel, or 
NU if the channel has not been used. 


is the number of times the channel has been dialed up. 


is the current state of the channel. It may have one of the following 
values: 


1 hung up 
2 listening (ready for dialup) 
5 dialed 


is an internal variable indicating what the answering service expects 
to happen next to the channel. 


is the activity code for the channel. It may have one of the following 
values: 


hung up 

listening (ready for dialup) 

dialed up but not logged in 

user is logged in but process not yet created 
user process has channel 

auto call line is in process of dialing out 
auto call line is in use (dial complete) 


“SOAUMN Ew h 


is the baud rate of the channel 


Person id 


“is the Person id of the current user of the channel. If A is not 4 


or 5, this field is omitted. 


Project id 


ID 


Is the Project id of the current user of the channel. If Ais not 4 
or 5, this fieId is omitted. 


is the identification of the terminal currently using the channel. 
If Sis not 5, this field is omitted. 


is the comment field from the CDT entry. 
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SECTION @ 
SUBROUTINES 
This section contains descriptions of subroutines useful for channel management 
and site communications administration. 


The conventions shown in the usage lines of these subroutines are the same 
as those used throughout the set of Muitics manuals. 
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Name: comm meters 


The comm meters subroutine, given a list of communications channel names, 
returns metering information for all the specified channels. The exact information 
returned for each channel varies depending on the line type and multiplexer type 
of the channel. Callers of ‘comm meters should later call the comm meters $free 
entry point to release the space allocated for the returned metering information. 


Usage 


del comm meters’ entry ((*) char (32), fixed bin, pointer, fixed bin, 
pointer, fixed bin (35)); 


call comm meters (chan names, version, area ptr, n channels, 
chan meters ptr, code); 


where: 


Tie chan names (Input) 
~ is an array of channel names, any of which may be starnames. 


2. version (Input) 
is the version number of the channel meters structure to be returned. 
It must be 1. = 


3. area ptr (Input) 
™~ is a pointer to an area in which the returned metering information 
is to be allocated. It must be a nonnull pointer. 


4, n channels (Output) 
S is the number of channels for which metering information is returned. 


pe chan meters ptr (Output) 
~ is a pointer to a linked list of structures containing the returned 
metering information. 


6. code (Output) 
is a standard system status code. 


Tw + a; ce | - | er a re oy - Lh bs ie] eee .= th 2 2 
The structure pointed to by chan meters ptr has the following format, which is 


defined in the include file channel meters.inel.pli: 
del channel meters aligned based (chan meterp), 
version fixed bin, 7 
multiplexer type fixed bin, 

parent type fixed bin, 

line type fixed bin, 

flags, 

3 reserved bit (36) unaligned, 

padi fixed bin, 

channel name char (32), 

mpx specific meterp pointer, 

parent meterp pointer, 

next channelp pointer, 

cumulative, 

3 unconverted input chars fixed bin (35), 


NP Ph Ph NM Po MPP PP — 
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3 converted output chars fixed bin (35), 

3 read calls fixed bin 

2 write calls fixed bin, 

3 control calls fixed bin, 

3 softwaré interrupts fixed bin, 

3 read call time fixed bin (71), 

3 write calI time fixed bin (71), 

3 control call time fixed bin (71), 

3 interrupt time fixed bin (71), 

3 pad (4) fixed bin, 
2 saved like channel meters.cumulative; 
version 


contains the value of the version argument (above). 


multiplexer type 
is the multiplexer type of the channel. It may have any of the values 
defined in multiplexer _types.incl.pl1. 


parent type 
is the multiplexer type of the channel's parent multiplexer. If the 
channel is a level-1 multiplexer (i.e., top-level multiplexer), 
parent type is set to -1. 


line type 
“is the line type of the channel. It may have any of the values defined 
in line types.incl.pl1. 


flags 
are reserved for future uSe. 


channel name 
is the name of the channel. 


mpx specific meterp 
“~ is a pointer to additional meters that vary according to multiplexer 
type. 


parent meterp 
is a pointer to additional meters maintained on behalf of the channel 
by its parent multiplexer. If the cnannei is a levei-i multiplexer, 
this pointer is null. 


next channelp 
“is a pointer to the channel meters structure for the next channel in 
the list. If this is the last channel, next_channelp is null. 


cumulative 
contains meters for the channel accumulated since the most recent bootload 
of the system. 


unconverted input chars 
is the number of characters input on the channel before conversion at 
the channel's multiplexing level. 


converted output chars 
is the number of characters output on the channel after conversion. 
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comm meters 


read calls 
“is the number of calls to channel manager$read for this channel. 


write calls 
Is the number of calls to channel manager$write for this channel. 


control calls 
is the number of calls to channel manager$control for this channel. 


software interrupts 
is The number of calls to channel manager$interrupt for this channel. 


read call time 
“is the amount of time (in microseconds) spent in read calls. 


write call time 
Is the amount of time spent in write calls. 


control call time 
is the amount of time spent in control calls. 


interrupt time 
is the amount of time spent processing software interrupts. 


Saved 
contains meters saved the last time the channel dialed up. They can 
be used in combination with the cumulative meters above to derive 
Statistics for the current dialup session. 


j Notes 


If comm meters encounters an error, it calls the sub err’ subroutine, raising 
the sub error condition with the restart flag on. The structure pointed to by 
Sub err info.info ptr has the following format, which is defined in the include 
file comm meters error info.incel.pl1: 


del 1 comm meters error info aligned based (comm meters errp), 
2 version fixed bin, i = 
2 chan name char (32), 
2 flags, 
3 starname matched bit (1) unal, 
3 more than one starname bit (1) unai, 
3 more than one match bit (1) unal, 
3 pad bit (33) unal; 
version 
| is the version number of the structure. It is set to comm meters err v1. 
chan name 
| ™ is the name of the channel being processed when the error was encountered. 
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starname matched 
"O"b error was encountered while matching a starname 
"1"b a starname provided by the caller was matched 


more than one starname 
"O%b the caller provided no more than one starname to chan names 
"1"b more than one starname was provided 


more than one match 
~ "1b starname currently being processed was matched by more than one 
channel name 
Meaningless if starname matched (above) is not "1"b 


Entry: comm meters $free 


This entry is called to release space allocated by comm meters’ to return 
metering information. Any program that calls comm meters — should subsequently 
call comm _ meters _$free to release the allocated space. 


Usage 


del comm_meters $free entry (pointer, pointer, fixed bin (35)); 


call comm meters $free (area ptr, chan meters ptr, code); 


where: 


1. area _ptr (Input) 
is a pointer to the area in which the space was allocated. 


2% chan meters ptr (Input) 
is a pointer to the list of metering structures returned by comm meters 
(above). 


3 code (Output) 
is a standard system status code. 


Entry: metering gate $get_ comm_meters 


This entry is identical in function to phces $get comm meters; it exists for 
the use of callers who lack access to the phes gate. The arguments are the 
Same as for phes $get_ comm meters. 
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Name: MPX meters __ 


This is a generic name for a collection of utility subroutines for managing 
meters specific to various multiplexer types. The string "MPX" in the name 
represents the name of a multiplexer type, asdefined in multiplexer types.inel.pl1; 
thus, the actual subroutines have names such as tty meters , mcs meters , 
vip7760 meters , etc. os ~ a 


Entry: MPX meters $allocate _ mpx 


The allocate mpx entry allocates a structure for meters maintained by a 
multiplexer for channels of that multiplexer type; @.8., 
vip7760 meters $allocate mpx allocates the metering structure for a vip7760 channel 
itself.” = = 


Usage 


declare MPX meters fallocate mpx entry (pointer, pointer, fixed bin (35)); 


eall MPX meters $allocate mpx (area ptr, meter ptr, code); 


where: 


1s area ptr (Input) 
~ is a pointer to an area in which the metering structure is to be 
allocated. 


2s meter ptr (Output) 
~ is a pointer to the allocated metering structure, whose format depends 
on the multiplexer type. If the entry is being called in preparation 
for a call to metering gate $get comm meters, the value of this pointer 
should be assigned to get comm meters info.subchan ptr. 


3. code (Output) 
is a standard system status code. 


Entry: MPX meters $allocate subchan 


This entry allocates a structure for meters maintained by the multiplexer 
for its subchannels; e.g., vip7760 meters $allocate subchan allocates space for 
meters kept by the vip7760 multiplexer modules for subchannels of a vip7760 
channel. 
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Usage 


declare MPX.meters Sallocate subchan entry (pointer, pointer, fixed bin 
(35). 5° 7 ~ 


call MPX meters allocate _subchan (area ptr, meter ptr, code); 
Arguments are the same as for the allocate mpx entry, above. If the entry is 


called in preparation for a call to metering gate ¢$get comm meters, the value of 
meter ptr should be assigned to get_comm_ meters info.parent ptr. 


Entry: MPX meters $free mpx 


This entry is used to free the storage allocated by the MPX meters S$allocate mpx 
entry, above. > ~ 


Usage 


declare MPX meters ¢free mpx entry (pointer, fixed bin (35)); 


eall MPX meters $free mpx (meter ptr, code); 


where: 


Ase meter ptr (Input) 
~ is a pointer to the metering structure to be freed. 


2 code (Output) 
is a standard system status code. 


Entry: MPX meters $free subchan 


This entry is used ive) free the storage allocated by the 
MPX meters $allocate subchan entry, above. 


Usage 


declare MPX meters $free subchan entry (pointer, fixed bin (35)); 


call MPX meters $free_ subchan (meter ptr, code); 


Arguments are as for the free mpx entry, above. 
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Entry: MPX meters $display_mpx 


This entry displays, on a specified I/O switch, the meters associated with 
a multiplexer of the specified type. The format of the statistics displayed 
depends on the type of multiplexer. These entries are called by commands that 
display general communications meters. 


Usage 


del MPX meters $display mpx entry (char (*), pointer, pointer, bit (36) 
aligned, Fixed bin (35)); 


call MPX meters $display_mpx (chan_name, iocb ptr, meter ptr, flags, code); 


where: 


Vs chan name (Input) 
~ is the name of the multiplexer channel for which statistics are to 
be displayed. 


2. iocb ptr (Input) 
~ is a pointer to the I/0 control block for the I/0 switch on which 
the meters are to be displayed. If it is null, the user output 
Switch is used. - ; 


3. meter ptr (Input) 
~ is a pointer to the structure returned by the comm meters subroutine 
for the channel specified by chan_name (above). ~ 


yy, flags (Input) 
indicates the control arguments specified to the channel comm meters 
command to control the format of the output. The individual flags 
are defined as follows: 


bit 1 - "1"b if -brief specified 
bit 2 - "{"b if -error specified 
bit 3 - "1"b if -summary specified 
bit 4 - "{"b if -since bootload specified 
bits 5-36 - reserved = 
These values are defined in the include file 


comm_meters disp flags.incl.pl1. 


Be code (Output) 
is a standard system status code. 
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ava wa 


This entry displays, on a specified I/O switch, meters kept by a multiplexer 
of the specified type on behalf of one of its subchannels. The format of the 
displayed meters depends on the multiplexer type. 


Usage 
del MPX meters $display subchan entry (char (*), pointer, pointer, bit (36) 
aligned, fixed bin (35)); 
call MPX_meters $display_subchan (chan name, iocb ptr, meter ptr, flags, 


code); 


Arguments are the same as for the display mpx entry, above. 
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Name: metering gate $comm_chan star list 


This entry returns a list of communications channel names that match a 
given starname, along with information on each channel's multiplexer type and 
line type. 


Usage 


declare metering gate $comm chan star list entry (char (*), fixed bin, 
pointer, pointer, fixed bin (35)); 


call metering gate $comm chan star list (starname, version, area ptr, 
chan star list ptr, code); — ~ 


where: 


lis starname (Input) 
is the starname to be matched. Its length must not be more than 32 
characters. See the description of starnames in the MPM Reference 
Guide for information on the construction of starnames. 


Zs version (Input) 
must be 1. 


ce area ptr (Input) 
~ is a pointer to an area in which the channel information is to be 
allocated. It must be a nonnull pointer. 


4, chan star list ptr (Output) 
~ isa pointer to the structure in which the channel information is 
returned. See "Notes," below, for a description of this structure. 


5a code 
is a standard system status code. It may have one of the following 
values: 


error table $badstar 
Starname is not a valid starname. 


error table ¢nomatch 
no channel names were found that match starname. 


error table ¢noalloc 
there was insufficient space to allocate the structure for 
the channel information. 

error table $unimplemented version 


Ehe version argument (above) did not contain the current 
version of the information structure. 


no errors. (Output) 
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Notes 


The structure pointed to by chan _star_list_ptr has the following format 
(described in chan_star_info.incl.pl1): 


del 1 chan_star_info based (chan_star_list_ptr) aligned, 

2 version fixed bin, 

2 n_channels fixed bin, 

2 chan_entry (chan_star_count refer (chan_star_info.n_channels)), 
3 name char (32), 
3 mpx type fixed bin, 
3 parent_type fixed bin, 
3 line_type fixed bin; 


version 
is the version number of the structure. 


n_channels 
is the number of channels matching the starname. 


chan_entry 
contains information for each channel matching the starname. 


name 
is the name of the channel. 


mpx_type 
is the multiplexer type of the channel. It may have any of the values 
defined in mulitplexer_types.incl.pll. 


_vype : 
is the multiplexer type of the channel's parent multiplexer. If the 
channel is a level-1 multiplexer, parent_type is -1. 


line type 
“is the line type of the channel if the channel is a physical subchannel 
of an FNP, in which ease it may have any of the values defined in 
line_types.incl.pl1; otherwise, it is 0. 
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Name: phes $get comm _ meters 


This entry is used to copy communications metering information for a 
specified channel from ring 0. Logical channel meters for the specified channel 
are returned, as are any multiplexer-specific meters maintained for the channel 
by its own multiplexer module or that of its parent. 


Usage 


del phes $get_comm_meters entry (char (*), pointer, fixed bin (35)); 


call phes $get_comm_ meters (chan_name, info ptr, code); 


where: 


1's chan_name (Input) 
is the name of the channel. 


2. info ptr (Input) 
~ is a pointer to a structure of the same form as that described for 
the get_ meters control order described in the tty description in 
the Subroutines manual. ~ 


3. code (Output) 
is a standard system status code. 
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DIRECTIONS FOR SETTING UP SYSTEM-SUPPLIED MULTIPLEXERS 


This appendix describes various aspects of the administration and use of 
the system-supplied multiplexers on Multics: 


HASP workstations or HASP hosts 

IBM3270 

polled VIP 

software-simulated terminals 

X.25 network connections 

foreign system connections through a protocol converter 


BBBeBB ES 


ADMINISTRATION AND USE OF HASP WORKSTATIONS AND HOST SYSTEMS 


Multiecs provides support for the HASP communications protocol. Multics can 
be configured to operate either as the host or as the workstation. As a host, 
Multics communicates with a remote workstation that is usually a remote- 
job-entry (RJE) terminal with an operator's console and one or more card 
readers, line printers, and card punches. As a_ workstation, Multics simulates 
an RJE terminal and communicates with a remote host system. 


The HASP communications protocol is supported by uSing the demultiplexing 
features of the Multics Communications System. This mechanism allows each 
device of the remote workstation or each simulated device, when Multics is the 
workstation, to be controlled independently by separate processes. Each device 
must be configured as a slave channel. 


A process using a device channel should attach that channel through either 
the hasp _workstation_ or hasp host _ 1/0 module described in the Subroutines 
manual. 


The FNP Core Image 


Support of the HASP communications protocol requires that the proper 
software he loaded into the FNP sunnorting the terminal oor remote system. The 
two modules, bse tables and hasp tables, must be bound into the core image 
before the FNP is’ loaded. (See Section 6 ("FNP Core Images") and the 


description of the bind fnp command in Section 7.) 
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Definition of HASP Channels 


HASP channels, like all communications channels, are defined in the Channel 
Master File (CMF). An entry must be made in the CMF for the remote workstation 
or host (the multiplexer channel) and for each of the individual devices. A 
sample excerpt from a CMF is shown below. 


name: a.h0O14; /® the workstation itself ¥*/ 
service: multiplexers; - 

multiplexer type: hasp; 

line type: BSC; 

baud: 4800; 

terminal type: HASP_WORKSTATION; 


name: a.hOl4.opr; /*® entry for operator's console */ 
service: slave; 
line type: BSC; 


name: a.-hO14.rdri-a.h014.rdr33 /*® entry for three card readers */ 
service: slave; 
line_type: BSC; 


name: a.h0O14.prti-a.hOl4.prt5; /* entry for five line printers */ 
service: slave; 
line type: BSC; 


name: a.-h014.pun1; /*® entry for one card punch */ 
service: slave; 
line_type: BSC; 


The above configuration defines a remote workstation with an operator's 
console, three card readers, five line printers, and a single card punch. For 
the major channel (a.-h014), the line type, service, and multiplexer type must be 
specified exactly as shown. The terminal type is used to distingufsh between a 
connection to a remote workstation and one to a host and to specify options 
controlling the connection. (This mechanism is described in detail in "Multiplexer 
Terminal Types," below.) 


The names of the subchannels (a.h014.*) must be created according to the 
following rules: 


& An operator's console must be included in every multiplexer. The console 
is the subchannel whose final component name is "opr." 


@ A maximum of eight card readers are permitted. A card reader is a 
subchannel whose final component name is of the form "rdrN", where N 
is a single digit between one and eight. 

® The combined number of iine printers and card punches must not exceed 
eight. For example, a multiplexer may have eight line printers and no 
ecard punches, or three line printers and five card punches; however, a 
multiplexer cannot have five line printers and five card punches. A 
line printer is a subchannel whose final component name is of the form 
"prtN", where N is a single digit between one and eight. A card punch 
is a subchannel whose name final component is of the form "punN", 
where N is also a digit between one and eight. 


NOTE: Due to a restriction in the HASP communications protocol, a 
multiplexer may not contain a line printer and card punch whose device 
addresses total nine. (For example, "prt4" and "pun5" can not be 
configured in the same multiplexer.) 
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Multiplexer Terminal Types 


All terminal types, including multiplexer terminal types, are defined in 
the Terminal Type File (TTF). The standard Multics TTF does not contain any 
HASP multiplexer terminal types. 


The Multics HASP support must distinguish between communicating with a 
workstation and a host. Additionally, the software must also be aware of certain 
characteristics of the communications channel (e.g., maximum message block length). 


The configuration information for a HASP multiplexer channel is supplied by 
using the value of the additional info keyword of the multiplexer channel's 
terminal type. The additional info value is formatted as a series of parameter 
assignments, separated by spacés or commas. Each parameter assignment has the 
following form: 


<parameter type>=<parameter value> 


A sample TTF entry for a multiplexer terminal type might appear as follows: 


terminal type: HASP HOST; 
additional info: "Eypeshost, block size=512, Signon_mode=no"; 


The complete set of parameters that may be specified is shown below (defaults 
are provided for all omitted parameters). 


name: type 

values: workstation or host 

default: workstation 

meaning: specifies whether this multiplexer is connected to a remote 
workstation or a remote host. 


name: block size 
Values: 400 through 1017 


defauit: 4606 
meaning: specifies the maximum block size, in characters, used by Multics 
for all messages transmitted on the multiplexer channel. 


name: Signon mode 

values: yes or no 

default: no 

meaning: when connecting to a remote host, specifies that Multics must 
transmit a SIGNON control record to identify Multics to the remote 
host before any data may be transmitted; this parameter is ignored 
when connecting to a workstation. 


name: multileave mode 

values: yes or no 

default: yes 

meaning: specifies that blocks transmitted by Multics may contain records 
from more than one device. This parameter may need to be turned 
off for communications with some workstations. 


name: suspend all mode 

values: yes or no 

default: no 

meaning: specifies that when Multics wishes to temporarily stop input for 
a specific device (flow control), the system will instead request 
that all input be suspended. This parameter may need to be turned 
on for communications with some workstation (e.g., an IBM System/370 
running the HASP workstation simulation option of RSCS under VM/370). 
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name: rts mode 

values: yes or no 

default: yes if type is host; no if type is workstation 

meaning: specifies whether Multics will request permission from the remote 
host or workstation before transmitting data on other than the 
operator's console. 


name: connect timeout 

values: 1 through 60 or none 

default: 30 

meaning: when connecting to a remote host, specifies the period (in seconds) 
to attempt the initial connection sequence after the physical 
connection is established; when connecting to a remote workstation, 
Specifies the period to wait for the initial connection sequence 
after the physical connection is established. If the string "none" 
is used, the multiplexer will either wait or send the initial 
connection sequence indefinitely as appropriate. 


name: receive timeout 

values: 1 through 60 

default: 3 

meaning: specifies the period (in seconds) to wait for a message to be 
received from the remote workstation/host before assuming that 
the last block transmitted by Multics was lost and should be 
retransmitted. 


name: transmit timeout 
values: 1 through 60 
default: 2 


meaning: when connecting to a remote host, specifies the period (in seconds) 
for the FNP to wait for a block from Multiecs to be transmitted 
before automatically acknowledging the last block received from 
the host; this parameter is ignored when connecting to a remote 
workstation. 


name: max naks 

values: 5 through 100 

default: 10 - 

meaning: specifies the maximum number of consecutive NAKs that may be 
transmitted or received by the FNP on the communications channel 
without an intervening block before aborting the connection. 


name: max device input records 
value: 3 through 30 = 
default: 6 


meaning: specifies the maximum number of records that the multiplexer will 
hold as input for a subchannel before requesting the remote system 
or workstation to suspend transmission for that subchannel. For 
optimum operation, this parameter should be given a value that is 
larger than the average number of records in an input block as 
reported by channel comm_meters for the multiplexer channel. 


Subchannel Terminal Types 


All data transmitted over a HASP subchannel must be both translated to the 
character set, normally EBCDIC, of the remote host or workstation and formatted 
according to the rigid requirements of the HASP communications protocol. 
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These functions are performed by the hasp host and hasp workstation I/0 
modules described in the Subroutines manual. A terminal type may be specified 
in the attach descriptions of these I/O modules to define the remote host's or 
workstation's character set. See the section "Character Set Specification" in 
the descriptions of these I/O modules for more information. 


ee eee 


The following control ‘orders are. recognized for HASP subchannels in 
addition to the control orders defined in the description of the tty I/0 module 
in the Subroutines manual. These control orders are intended to be used 
exclusively by the hasp workstation and hasp host _ I/0 modules and should not 
be invoked by user programs. 


In the following descriptions, the “info ptr" field supplies the 
declaration of the item that must be supplied by the caller to the HASP 
multiplexer software. An indication is aiso supplied as to whether the cailer 
must also supply any information in the field before issuing the control order 
(Input vs. Output). 


name: get device type 
funetion: returns the type of device (operator's console, card reader, line 
printer, or card punch) connected to the subchannel. 
info ptr: fixed binary (35) (Output) 
notes: the possible values returned by this control order are defined in 
the include file hasp device data _incl.pl1. 
return codes: = ~ 
0 the device type is supplied in the given field 
error table $undefined order request 
this channel is not part of a HASP multiplexer. 


name: - Signon_ record 

name; no signon record 

function: see the section "SIGNON Processing" in the write-up of the 
hasp host 1/0 module in the Subroutines manual, 


ADMINISTRATION AND USE OF IBM3270 TERMINALS 


eee eee 


Multics provides support for IBM Model 3271 terminal systems as login 
devices. These systems comprise a cluster of keyboard/display stations and 
receive-only printers that can be connected to Multics via a_ single shared 
communications line. Multics uses the IBM3270 bisyne protocol to control these 
devices. 


The IBM3270 terminal system is supported using the demultiplexing features 
of the Multics Communications System. This allows each device on the controller 
to be controlled independently by separate processes. Each keyboard/display 
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receive-only printers can only be configured as slave channels. 


Note that configuring an IBM3270 channel for use as a multiplexer is 
incompatible with the existing ibm3270 I/O module, which requires that the 
channel be configured as a slave. A 3270 terminal system can be controlled by a 
Single process as a slave device by using ibm3270 , or can’ be controlled by 
multiple processes as login devices using the IBM3270 demultiplexer. 
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The FNP Core Image 


Support of IBM3270 terminals requires that the proper software be loaded 
into the FNP supporting the terminal. The two modules required are bsc tables 
and ibm3270 tables. Both of these modules must be bound into the core image 
before the FNP is loaded. (See Section 6 ("FNP Core Images") and the description 
of the bind _fnp command in Section 7.) 


Definition of IBM3270 Channels 


IBM3270 channels, like all communications channels, are defined in Channel 
Master File (CMF). An entry must be made in the CMF for the subsystem or 
controller and for each of the subchannels. A sample excerpt from a CMF is 
shown below. 


name: a.h012; /* entry for controller ¥*/ 
baud: 9600; 
line type: BSC; 
service: multiplexer; 
multiplexer type: ibm3270; 
terminal type: IBM3271; 


name: a.h012.d00-a.h012.d03; /* entry for 4 displays */ 
attributes: hardwired, dont_read_answerback; 

line type: BSC; 

service: login; 

terminal type: IBM3277_M2; 


name: a.h012.p04; /* entry for 1 receive-only printer */ 
line type: BSC; 

service: slave; 

terminal type: IBM3284 M2; 


The above configuration defines a system with four keyboard/display stations 
and one printer. For the major channel (a.h012), the line type, service, and 
multiplexer type must be specified exactly as shown. The terminal type is used 
to distinguish between various types of 3270 subsystems, and is explained below. 


The names of the subchannels (a.h012.¥*) must be in a specific format. The 
final component must be exactly three characters. The first character must be 
"pn" for printer channels or "d" for keyboard/display stations. The final two 
characters must be two decimal digits that define the device address. The multiplexer 
cannot be configured with a printer and a display that have the same address. 


Multiplexer Terminal Types 


The terminal type for the multiplexer channel specifies options to distinguish 
between various kinds of 3270 systems. The following standard multiplexer terminal 
types are defined in the Terminal Type File (TTF) (additional types may be 
defined by an administrator, as required):. 


1BM3271 
1BM3271_ASCII 
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protocol. 


The IBM3271 terminal type is for use in configurations using the EBCDIC bisyne 
The IBM3271 _ASCIT type is for use with the ASCII protocol. 


The only portion of the TTF entry for the multiplexer terminal type that is 


used is the "additional info" 
the value of various parameters used to control multiplexer operation. The 
j is formatted as a 


keyword. The character string is used to specify 


series of narameter assignments senarated »b 
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Each parameter assignment has the following form: 


<parameter type>=<parameter_value> 


A sample TIF entry for'a multiplexer terminal type might appear as follows: 


terminal type: IBM3271; 


additional info: 


"controller address=1 quit=pae"; 


The complete set of parameters that may be specified is shown below (defaults 


name: 
values: 


default: 
meaning: 


name: 
values: 


default: 
meaning: 


name: 
values: 


default: 
meaning: 


name: 
values: 


default: 
meaning: 


name: 
values: 


default: 
meaning: 


are provided for all omitted parameters). 


controller address 

0 through 31 

0 

specifies the device address of the controller to be used for 


polling. (Multiple controller configurations on a_e single 
communications channel are not supported.) 

quit 

pail, pa2, or pa3 

pat 


specifies which function key is to be interpreted as the Multics 
quit function. 


formfeed 

pal, pa2, pa3, or clear 

clear 

specifies which function key is to be interpreted as restarting 
output on an end-of-page situation. 


code 

ascii or ebcdic 

ebedic 

specifies which character code is to be used. 


allow raw3270 

yes or no 

yes 

specifies whether users of subchannels of this multiplexer may 
use the special mode "raw3270". This mode is intended for forms 
control and is explained in more detail below. 
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name: allow copy 

values: yes or no 

default: no 

meaning: specifies whether or not users of raw3270 mode may make use of 
the 3270 copy function. Enabling this function allows a user of 
one subchannel to "copy" the memory of another subchannel. This 
could, in malicious hands, compromise the passwords of users on 
other subchannels. 


name: debug 

values: yes or no 

default: no 

meaning: specifies that the ring-0 portion of the 2270 demultiplexer may 
write certain debugging information on the syserr console. This 
is used only by demultiplexer developers. 


Subchannel Terminal Types 


Terminal types for subchannels are also provided in the standard TTF. The 
following terminal types, which correspond to IBM model numbers, are provided: 


displays: IBM3277 M1 
IBM3277 M2 
IBM3277 M1 ASCII 
IBM3277 M2 ASCII 

printers: IBM3284°M1_ 
IBM32@4 M2 


Typing Conventions 


A 3270 subchannel is not considered usable (or dialed) until some input is 
received from it. Therefore, the first step in using a 2270 keyboard/display is 
to activate or press any of its input keys (usually "enter", but "clear", or any 
of the "pa" or "pf" keys may be used also). In response to this first input 
(which is discarded), Multics clears the screen and sends the standard greeting 
message. 


The 3270 demultiplexer uses an unformatted screen in controlling the display. 
It also controls the keyboard unlocking feature and only unlocks the keyboard 
when the process is ready for more input. Unlocking of the keyboard can be 
regarded as a prompting function; the previous input has been acted upon, and 
the process is ready for input again. 


When typing input on a 2270 display unit, the following rules must be 
followed: 


1. Always begin typing where the system positions the cursor. 


2. Always leave the cursor after the last character of input. Local 
editing functions of the terminal may be used to edit an input line, 
but the cursor must always be returned to the end of the line of 
input. 


ce Always terminate input with the "enter" key. 


, Never attempt to send more than one line of input using the return key 
of the terminal. Single lines of input longer than the line length of 
the terminal may be sent normally by allowing the terminal to wrap at 
the end of the line (except on the last line of the screen). Multiple 
lines are not possible. 
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54 When typing over a password mask (printer off is not supported), either 
Space out over the end of the mask (after the password is typed), or 
use the erase eof function to delete the end of the mask. One of 
these options must be performed before using the "enter" key. Failure 
to do this properly results in part of the password mask being interpreted 
as input. 


6. The terminal's tab key may not be used to enter tabs into the input 
text. The only way to enter a tab is to use the escape sequence ¢11. 


These typing conventions must be followed exactly. Failure to do so may 
cause input to be ignored, lost, or misinterpreted. 


The formfeed function code (normally pail) as defined in the multiplexer 
terminal type has two uses. First, when output is suspended at the end of the 
screen (EOP on the last line), the formfeed causes the next page of output to be 
sent. If the terminal is not in an EOP situation, it causes the screen to be 
cleared and new input and output to begin at the top of the screen. 


The 3270 does not implement the full ASCII character set. Therefore, the 
following conventions are used: 


ASCII 3270 


\ @ (cent sign) 
£< 
é£> 
£( 
¢) 
gi 
ét 


| ne en A ee | 


These conventions are the same as used by Multics for IBM2741 terminals. 


raw3270 Mode 


The 3270 demultiplexer implements a special mode named "“raw3270". This 
mode is set and reset like all other tty modes, using the same command and 
subroutine interfaces. This mode is intended for forms programs, and is used to 
make the full set of 3270 features available to the user. The mode may be set 
by the user (if allowed by the multiplexer terminal type, see above) at any 
time. It does not go into effect, however, until rawo and rawi modes are also 
set. When raw3270 mode is in effect, the user is expected to format a complete 
3270 bisyne message, including the STX and ETX, but excluding the leading SYN 
and the trailing block check characters. This message, with some minimal checking, 
is sent unchanged to the terminal. The function code (following the STX-ESC) 
may be either write, erase write, or copy (if allowed by the multiplexer terminal 
type). Read buffer, read modified, and erase all unprotected are not Supported. 


When raw3270 mode is in effect, input is not interpreted by the multiplexing 
software (except for messages caused by the TEST REQ key); it is passed to the 
user exactly as received from the terminal. The only change that occurs is to 
combine multiple input messages from the terminal into a single bisyne message 
when the terminal has split its input into multiple records because it exceeded 
256 characters. 


A-9 CC75-01 


Also, when raw3270 mode is in effect, the hndlquit mode takes on an additional 
meaning. If hndlquit is on, the quit key defined for the multiplexer is processed 
normally; this function key is unavailable for user programs. If the channel is 
in “handlquit mode, no quit processing takes place and the quit key may be used 
by the application as it sees fit. Note that in “hndlquit,raw3270 mode there is 
no way to perform a Multics quit function. 


Special care must be taken by the application program when operating in 
raw3270 mode. Any unexpected output to the terminal (e.g., messages from other 
users, memos, and error messages) will be ill-formatted, may not appear on the 
user terminal, and may have unpredictable side effects. It is important for the 
application program to anticipate all possible error conditions, because the 
default error handler may’ not return the terminal to a usable state when a 
condition occurs. Thus, in raw3270 mode, when an error occurs, and the user is 
returned to command level, there may be no way for him to enter a command since 
the process is expecting complete bisyne messages from the terminal. 


ADMINISTRATION AND USE OF POLLED VIP TERMINALS 


The Multics Communications System provides support for several Honeywell 
VIP terminal subsystems including the VIP7700, VIP7760, and VIP7804. These 
Subsystems typically comprise a number of keyboard/display stations and receive-only 
printer stations that can be connected to Multics via a single communications 
line. The Honeywell polled VIP communications protocol supports these terminals. 


The Multics Communication System contains a multiplexing mechanism that 
allows each station of a polled VIP subsystem to be independently controlled. 
Thus, each keyboard/display station can be used as a separate login terminal. 
Similarly, each printer station can be used as a slave device attachable by any 
authorized process, such as an I/0 daemon (see Multics Bulk I/0 for information 
about I/O daemons). 


The FNP Core Image 


Support of polled VIP terminals on Multics requires that a particular software 
module, known as polled vip tables, be present in the FNP core image. To accomplish 
this, the bindfile muSt be changed to include polled vip tables. A new core 
image must then be generated to replace the previous one. For further details, 
see Section 6 ("FNP Core Images") and the description of the bind fnp command in 
Section 7. . 


Definition of Polled VIP Channels 


eee 


A channel must be defined in the Channel Master File (CMF) for each terminal 
Subsystem, i.e., for each polled VIP communications line connected to Multics. 
This channel is known as a multiplexer channel because it connects the entire 
Subsystem. For each station in the subsystem, another channel must be defined 
in the CMF. These channels are referred to as subchannels of the multiplexer 
channel. A sample excerpt from the CMF is shown below in which a multiplexer 
channel and various subchannels are defined. For a complete description of the 
CMF, see Section 4. 
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name: a.h005; 
baud: 2400; 
dataset: 201C; 
line type: POLLED VIP; 
service: multiplexer; 
multiplexer type: vip7760; 
terminal type: VIP7700 CLUSTER; 


name: a.h005.d00-a.h005.d01; 
attributes: dont read answerback; 
service: login; — 7 
terminal type: VIP77(C5; 


name: a.n005.p01; 
service: slave; 

baud: 1200; 

terminal type: VIP7714; 


The above example shows a polled VIP multiplexer witn three subchannels: 
two displays and one printer. It is essential that the line type and multiplexer type 
be specified as shown. The multiplexer type of vip7760 is used generically for 
all polled VIP multiplexer channels. It does not imply that the subsystem must 
be a VIP7760. The terminal type of the multiplexer channel distinguishes the 
different types of subsystems. More will be said about this later. 


The names of subchannels are chosen according to specifie rules. The final 
component of the subchannel name must be exactly three characters. The first 
character must be "d" for a keyboard/display station, "p" for a printer station, 
or "x" for a transparent communications channel using the polled VIP protocol. 
The last two characters represent the station poll address. Note that a 
keyboard/display station can share the same poll address with a printer station. 


A baud rate should be specified for printer subchannels to distinguish 
between 300 and 1200 baud printers. 


Printer subchannels should not be defined for a VIP7804 subsystem. On the 
VIP7804, a printer is treated as a peripheral device of the keyboard/display 
Station to which it is connected. The printer can only be addressed by the use 
of escape sequences within the text sent to the keyboard/display station. Therefore, 
VIP7804 printers cannot be supported as independent subchannels. 


Multiplexer Terminal Types 


All terminal types, including multiplexer terminal types, are defined in 
the Terminal Type File (TIF). The standard Multics TIF contains three polled 
VIP multiplexer terminal types that correspond to three different subsystems: 


VIP7700 CLUSTER 
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VIP7804~ CLUSTER 
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The differences among polled VIP subsystems have been categorized according 
to a set of parameters that control the behavior of the polled VIP multiplexer 
software within the Multics Communication System. The additional info field of 
the multiplexer terminal type is used to specify the values of these parameters. 
This field is formatted as a character string containing a sequence of parameter 
assignments separated by spaces. Each parameter assignment has the following 


form: 


<parameter type>=<parameter value> 


A sample multiplexer terminal type would appear in the TTF as follows: 


terminal type: VIP7700 CLUSTER; 
additional info: "controller poll=no quit=q formfeed=1"; 


Default values apply to any parameters not specified or to all parameters 
if no terminal type is specified. The complete set of parameters is described 


below. 


name: 
values: 


default: 
meaning: 


name: 
values: 


default: 
meaning: 


name: 
values: 


default: 
meaning: 


name: 
values: 


default: 
meaning: 


name: 
values: 
default 


meaning: 


name: 
values: 


default: 
meaning: 


name: 
values: 


default: 
meaning: 


controller poll 

yes, no — 

no 

if yes, indicates that the subsystem responds to a controller 
poll. 


erlf echo 

yes, no 

no 

if yes, indicates that Multics echoes a carriage return/linefeed 
sequence after each input message is received. 


omit nl 


if no, Multics appends a newline character to the end of each 
input message. 


omit ff 

yes, no 

no 

if no, Multics sends a formfeed character to clear the screen 
before resuming output after an end-of-page condition. 


gcos break 

yes, no 

no 

if yes, Multics recognizes an input message containing the string 
$*$BRK as a quit indication. 


etb mode 
yes, no 
no 


if yes, Multics terminates partial message blocks transmitted to 
the terminal with an ETB character instead of an ETX character. 
This ensures that escape sequences that are split across blocks 
are correctly interpreted by the terminal. (Note: The VIP7700 
does not support etb mode.) 


pause time 

integer N where N >= 0 

1000 

specifies the pause time in milliseconds between consecutive poll 
cycles. 
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name: max text len 

values: integer WN where 508 <= N <= 1920 

default: 1024 

meaning: specifies the maximum number of data characters in any message 
transmitted by Multics to the terminal. 

name: max message len 

values: integer N where 73 <= N <= 1024 

default: 289 

meaning: specifies the maximum number of characters expected in an input 
message from the terminal. This parameter is normally not specified 
except on channels used for Level-6 file transfer. 

name: quit 

values: any Single ASCII character 

default: q 

meaning: when this character appears in the first function code position 
of an input message, it indicates a quit. 

name: formfeed 

values: any single ASCII character 

default: 1 

meaning: when this character appears in the first function code position 


of an input message, it indicates a formfeed operation. 


Subchannel Terminal Types 


Terminal types for polled VIP subchannels are specified in exactly the same 


way as terminal types for ordinary asynchronous channels. 
contains three terminal types that apply to polled VIP keyboard/display subchannels: 


The standard TTF 


VIP7705 /* VIP7700 display with upper/lower case */ 
VIP7760 /*® VIP7760 display */ 
VIP7&804 /* VIP7&804 display */ 


Printers for polled VIP subsystems are one of two basic types: 


TermiNet 


or Rosy. The standard TIF contains two corresponding terminal types named TN300 
and ROSY. Also, a VIP7714 terminal type is defined that is essentially equivalent 
to TN300. 


For keyboard/display stations used as login terminals, the CMF subchannel 
entry should specify the appropriate terminal type. For slave subchannels (normally 
printers), the terminal type must be set after the device is attached. 


Input Size Considerations 


A single transmission from a polled VIP terminal can contain any number of 
characters and any number of lines. In the normal case, Multics expects to 
receive exactly one line with each transmission. When page-length mode is enabled, 
Multics counts each separate transmission as one line of input. Therefore, if 
more than one line is actually sent, Multics miscalculates the true cursor position. 
This can cause subsequent output to be improperly formatted. Therefore, normal 
use of a VIP7700 or VIP7760 terminal requires pressing the transmit key at the 
end of each line of input; the return key is not used. On the VIP7804, a mode 
of operation called "transmit on return" is provided that causes each line to be 
transmitted when the return key is pressed. This mode is recommended and its 
use is assumed in the discussions that follow. 
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If page-length mode is disabled for some special purpose, e.g., a forms 
processing application, the single-line input restriction can be ignored. In 
this case, there is no problem in transmitting multiple lines or an entire 
screen. 


Polled VIP terminals (or subsystems) have a strapping option that limits 
the maximum transmission block size to 256 data characters. Larger transmission 
requests are divided into a sequence of blocks. Multics expects this option to 
be selected and rejects input blocks containing more than 256 data characters, 
unless the max message len parameter (above) is specified. 


Function Codes 


Function codes are ordinary characters that occupy a special position within 
- the polled VIP message structure. Each time a polled VIP terminal transmits a 
message to Multics, the message contains two function codes. On the VIP7700 and 
VIP7760, these function codes can be set from the keyboard by pressing the 
control (CTL) key in combination with a regular key. On the VIP7&804, function 
codes are generated only by the 12 special-function keys at the top of the 
keyboard. 


Multics uses the first function code in a message as a means for indicating 
a quit or formfeed operation. This is necessary because the normal mechanisms 
for indicating these operations are not available. Like most other synchronous 
terminals, a polled VIP terminal does not transmit a line break and, consequently, 
does not have a break key. Also, a polled VIP terminal does not transmit certain 
ASCII control characters including formfeed. 


The transmission of function codes varies from one terminal to another. On 
the VIP7700 and the VIP7760, function codes, like data, are not transmitted 
until the transmit key is pressed. The VIP7700, however, does not transmit a 
function code unless data has been entered. Therefore, a VIP7700 user must type 
a data character in order to send a function code. Multics ignores any data 
that arrives in the same message with a recognized function code. The VIP7804 
is very different: when a special function key is pressed, a message containing 
a function code is transmitted automatically without any need to press the transmit 
key. 


QUITS 


As mentioned above, a polled VIP terminal does not have a break key. Therefore, 
a function code is used to indicate a quit. On the VIP7700 and VIP7760, the 
quit function code is normally "a". This code is generated by simultaneously 
pressing the control key and the Q key. On the VIP7&804H, the quit function code 
is normally an underscore ( ). This code is generated by simultaneously pressing 
the shift key and the F12 function key. The quit function code can be changed 
by use of the quit parameter described earlier. 


Since a quit discards output that has already been formatted by Multics, 
the cursor position computed by Multics is made invalid. This can cause subsequent 
output to be improperly formatted. Therefore, whenever a user issues a quit 
while output is pending, the user should next issue a formfeed to resynchronize 
Multics with the true cursor position. Normally, this is only necessary if the 
user quits while at end of page. 
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FORMFEEDS 


As mentioned above, a polled VIP terminal does not transmit a formfeed 
character. Therefore, a function code is used to indicate a formfeed operation. 
On the VIP7700 and VIP7760, the formfeed function code is normally "1". This 
code is generated by simultaneously pressing the control key and the L key. On 
the VIP7804, the formfeed function code is normally a circumflex (*). This code 
is generated by the F12 function key (unshifted). The formfeed function code 
can be changed by use of the formfeed parameter described earlier. 


The formfeed function code is used to request Multics to clear the screen. 
This is often done before executing a command that produces a full page of 
output to avoid dividing the output between two pages. Although the user can 
clear the screen locally by use of the clear key, Multics is unaware of the 
change in cursor position. This causes subsequent output to be improperly formatted. 
Therefore, it is recommended that the clear key not be used. 


End of Page 


Normal use of a polled VIP terminal requires that page- length mode be 
enabled. When an end-of-page condition is encountered, the resumption of output 
can be requested in several different ways. One way is to send a formfeed 
function code. Unfortunately, function codes are not especially convenient to 
send on the VIP7700 or VIP7760 (several keystrokes are required). Since the 
end-of~page condition occurs often in normal use, a more convenient method of 
resuming output is provided. 


When at end of page, the transmission of any message to Multics is construed 
as a request to resume output. Therefore, on the VIP7760, a user need only 
press the transmit key. This sends an empty message to Multics. The VIP7700, 
however, does not transmit an empty message. Therefore, at least one data character 
must be typed. The commercial-at sign (@) is used for this purpose. When at 
end of page, if Mulitics receives a message containing only the "“@" character, 
output is resumed and the message is discarded. If the message has any other 
contents, it is treated as normal input, and output resumes. 


On the VIP7804, one can use either the return key or the formfeed function 
key to resume output. 


Blank Lines 


Typing a blank line requires merely pressing the transmit key on the VIP7760 
or the return key on the VIP7804. The VIP7700, however, does not transmit a 
blank line; on this terminal it is necessary to type a space before pressing the 
transmit key. 


Tabs 


Use of the tab key on a polled VIP terminal produces different effects from 
an asynchronous terminal. As with most buffered terminals, a tab is converted 
to the appropriate number of spaces when displayed on the screen. These spaces 
are what eventually get transmitted to Multics. Hence, a polled VIP terminal 
never transmits a tab control character. 
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An exception arises when a user types a tab at the beginning of a line. In 
this case, the tab is interpreted not as a shorthand for spaces, but rather as a 
Shorthand for moving the cursor right. The difference is that no space characters 
are entered on the screen, and, therefore, no spaces are transmitted. If the 
user really wants spaces, the problem can be avoided by always typing a space 
followed by a tab when at the beginning of a line. 


In order to create and edit text containing tabs, it is necessary for a 
polled VIP user to type an escape sequence that Multics translates into a tab 
character. Normally, the backslashh (\h) sequence is used to represent a horizontal 
tab. This sequence is defined by the special-characters table associated with a 
given terminal type. 


Circumflex and Tilde 


On the VIP7700 and VIP7760, the circumflex (*) and tilde (~) characters 
have special interpretations. The circumflex character causes blinking of 
Subsequent characters on the same line, up to the first space. The tilde character 
causes blanking of subsequent characters on the same line, up to the first 
Space, Multics, however, attaches no such special interpretation to these 
characters. Therefore, when Multics transmits these characters to the terminal, 
it is necessary to represent them without producing the blinking or blanking 
effect. 


On the VIP7760, this is accomplished by immediately following each circumflex 
or tilde with a space. This same technique cannot be used on the VIP7700 because 
it does not display the circumflex or tilde. Therefore, on the VIP7700, a 
circumflex is represented by the backslash minus sign (\-) sequence and tilde is 
represented by the backslash equal sign (\=) sequence. These sequences can also 
be typed as input on both the VIP7700 and VIP7760. ) 


Dialups and Hangups 


Individual stations on a polled VIP Subsystem do not "dial up" or "hang up" 
a communications line as do ordinary terminals. Therefore, these actions are 
Simulated to some extent. At the time a subsystem is initialized, all slave 
Subchannels are assumed to be dialed up, and all login subchannels are assumed 
to be hung up. To dial up a keyboard/display station, a user must send an input 
message of any kind. This message is discarded by Multics, but causes a simulated 
dialup to occur. Multics responds by sending a greeting message to the station. 
The user can then log in as usual. 


There is no way to produce a hangup condition from a polled VIP station. 
Switching off power to the station has no effect. Therefore, the only way to 
terminate a Multics session is by use of the logout command. After logout, a 
station reverts to the hung-up state. To begin a new session, the dialup and 
login procedure is repeated as described above. 


ADMINISTRATION AND USE OF SOFTWARE-SIMULATED TERMINALS 


EN NS RENN Ste 


Multiecs provides support for software-simulated terminals. These are "pipes" 
with simulated Multics terminal interfaces at either end. In the usual case, 
one end is configured as an autocall channel and the other as either a login or 
Slave channel. 
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Definition of Software Terminal Channels 


a ee ee 


software terminals, like all other communications channels, are defined in 
the Channel Master File (CMF). An entry must be made in the CMF for the 
software terminal facility, itself, as well as two for each pipe to be defined. 
A sample CMF excerpt is shown below. 


name: sty; /* entry for facility */ 
service: multiplexer; 
multiplexer type: sty; 
name: sty.slogin 001-sty.slogin 020; /* entry for server side 
~ a of login channels */ 
service: login; 
terminal type; STY; 


name: sty.sslave 001-sty.sslave 005; /* entries for server 
ma \ Slave channels */ 
service: slave; 
terminal type: STY; 


name: sty.ulogin 001-sty.ulogin 020; /* entries for user side 
a a of login channels */ 
service: autocall; 
terminal type: STY_USER; 


name: Sty.uSlave 001i-sty.uslave 005; /* entries for user sides 
~ = of slave channels */ 

service: autocall; 
terminal type: STY_USER; 


The above configuration defines a system with 20 software terminals for 
login service and five for slave service. Each one has two channels associated 
with it, the "server" and "user" sides. The server and user sides must have the 
same name, except for the first character of the last component, which should be 
"s" for servers and "u" for users. 


If you type ahead on a login service channel that expects an answerback, 
the typed-ahead data is interpreted as the answerback string, causing STY to be 
hung up. You can avoid this circumstance by specifying the dont read answerback 
attribute for the login STY. - 


Multiplexer Terminal Types 


The terminal types associated with software terminals (STY and STY_USER) 
define the conversions appropriate to these channels. 


Use of software-simulated terminals is incompatible with the access 
isolation mechanism (AIM). 
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SPECIFICATIONS FOR AND ADMINISTRATION OF X .25 NETWORK CONNECTIONS 


EN 


The Multics Communications System provides support for a connection to a 
packet switching network through an interface complying with 1980 CCITT 
Recommendation X.25. The networks certified for use include TYMNET, eee 
TELENET, and UNINET. 


The Multics Communications System contains a multiplexing mechanism that 
allows each logical channel through the network to be independently controlled. 
In this manner, it is possible to configure some logical channels as login 
terminals, while others may be used for outgoing access. 
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Hardware Requirements 


The X.25 interface runs only on a DCU6661 FNP with at least 64K words of 
memory. Each separate X.25 connection requires an HDLC interface feature. Those 
supported are: 


@ DCF6620 00-9600 bits/sec V.24 interface (RS232-C) 
e@ DCF6623 0-72000 bits/sec V.35 interface 
e DCF6622 0-72000 bits/sec Bell 3XX interface 


Software Support 


The X.25 communications protocol is an international standard that defines 
an interface to various public data networks. The information below describes 
various aspects of the X.25 interface as implemented on Multics systems. It is 
assumed that the user is familiar with the terminology used in defining the X.25 
international standard. 


LINK LEVEL (X.25 LEVEL 2) 


Both the LAPB and LAP link-level procedures are supported. Multics can act 
as either a DTE or DCE. The link-level parameters can be controlled on a per-link 
basis as follows: 


Timer (T1) 0-51.1 sec in units of .1 sec. 
Timer (T3) 1-511 sec 

Maximum Number of Transmissions (N2) 1-511 

Maximum Number of Bits in an I Frame (N1) 24-8232 in multiples of 8 bits 
Maximum Number of Outstanding I Frames (k) 1-7 


The link-level parameters are specified in the additional_info keyword used 
with the TTF entry for X.25 channels. See "Terminal Type File" below. 


PACKET LEVEL (X.25 LEVEL 3) 


Permanent Virtual Circuit and Datagram service are not supported. Up to 
4095 virtual circuits can exist. A "virtual circuit" is the equivalent of a 
logical channel. The maximum User Data field length can be any of 64, 128, 256, 
512, and 1024 octets and must be the same for all virtual circuits. The window 
size can be chosen from 1-7 and must be the same for all virtual circuits. User 
Data field length and window size are defined in the additional info keyword 
used with the TTF entry for X.25 channels. See "Terminal Type File™ below. Use 
of the More Data Mark (M bit) is not supported. Use of the Qualifier (Q) bit 
other than by X.29 is not supported. The following Optional User Facilities are 
not supported: 


Extended Packet Sequence Numbering 
Packet Retransmission 

Closed User Group 

RPOA Selection 

Flow Control Parameter Negotiation 
Throughput Class Negotiation 

Fast Select 
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TERMINAL CONTROL LEVEL 


In general, the terminal control protocol described by the 1980 CCITT 
recommendations X.3 and X.29 is supported. The X.3 parameters supported and 
corresponding Multics terminal modes are described below. (Multics terminal 
modes are specified as part of the TTF entry used to define each terminal. See 
the Programmer's Reference Manual for a description of the TTF.) 


1 PAD recall by escaping from the data transfer rawi 
state 
| 


2 Echo echoplex 
3 Selection of data forwarding signal always set to 126 
4 Selection of idle timer delay breakall 
5 Ancillary device control iflow 
7 Selection of operation of PAD on receipt of hndlquit 
break signal from the start-stop mode DTE 
8 Discard output used by interrupt procedure 
12 Flow control of the PAD by the start-stop oflow 


mode DTE 
13 LF insertion lfecho 
In addition, the following DATAPAC national parameters are supported: 


125 Output pending timer polite 
126 LF insertion lfecho 


Implementing an X.25 Capability on Multics 


— —— 


In order to obtain an X.25 capability on Multics, the user must: 
‘lie Add appropriate X.25 software to the FNP. 


2% Define the X.25 connection (physical channel) and the various terminals 
to be associated with the channel. 


3% Install a specially defined Terminal Type File (TTF). 


A description of each procedure is listed below. 


THE FNP CORE IMAGE 


Support of an X.25 connection on Multics requires that the software module 
"x25 tables" be present in the FNP core image. To accomplish this, the bindfile 
must be changed to include x25 tables, and a new core image must be generated. 
For further details see Section 6 ("FNP Core Images") and the description of the 
bind fnp command in Section 7. 
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DEFINITION OF X.25 CHANNELS 


-One channel must be defined in the Channel Master File (CMF) for each X.25 
network connection. Appropriate subchannels must be defined for each terminal 
to be associated with the multiplexed channel. A sample CMF follows. 


name: b.h102; 
baud: 9600; 
line type: X25LAP; 
service: multiplexer; 
multiplexer type: x25; 
terminal type: X25 DATAPAC; 


name: b.h102.001-b.h102.050; 
service: login; 
terminal type: ASCII; 


name: b.h102.051-b.h102.063; 
service: autocall; 
terminal type: none; 


The above configuration defines a connection to the network at 9600 baud 
through channel b.h102. Multics will behave as the DTE (the default type) and 
will use the basic X.25 protocol. There are 50 inward (login) channels and 13 
outward channels. 


TERMINAL TYPE FILE (TTF) 


The user must install a specially defined TTF to support the X.25 facility. 
The TTF must contain a site-specific entry for the X.25 connection. Examples of 
entries for TYMNET and DATAPAC are supplied in the TTF shipped with the system. 


The only portion of the TTF entry that is used is the “additional info" 
keyword. The character string is used to specify the value of various parameters 
used to control multiplexer operation. The parameters are all optional except 
"n le," which must be specified. The field is formatted as a series of parameter 
assignments, separated by spaces. 


A sample TTF entry for a X.25 multiplexer might appear as follows: 


terminal type: X25 TYMNET 
additional info: "network=tymnet n_le=32 packet size=128 window size=2 
= type=DTE link protocol=LAP frame size=8232 T1=3 N2=20 
T323-Ke7. = 


The complete set of parameters is listed below: 


name: type 

values: DTE, DCE 

default: DTE 

meaning: specifies whether the Multics system behaves as the DTE or DCE. 


name: link protocol 

values: LAP, LAPB 

default: LAP 

meaning: connection mode is either LAP or LAPB (Balanced). 
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name: 
values: 


default: 
meaning: 


name; 
values; 
default: 
meaning: 


name: 
values: 
default: 
meaning: 


name: 
values: 
default: 
meaning: 


name: 
values: 

default: 
meaning: 


name: 
values: 
default: 
meaning: 


name: 
values: 
default: 
meaning: 


name: 
values: 

default: 
meaning: 


name: 
values: 

default: 
meaning: 


dise first 

yes, no 

no 

specifies whether Multics enters the DISC SEND state. This 
should only be used for networks implementing the old TELENET 
X¥.25 protocols. 


frame size 

24 through 8232 in multiples of 8 

1064 

specifies the maximum size, in bits, of transmitted frames. This 
Size must be large enough to contain a packet whose length is 
packet size (see below) plus the level 3 header (3 or 4 
characters). 


K 

1 through 7 

ij 

specifies the number of outstanding unacknowledged frames 
allowed. 


N2 

1 through 511 

20 

specifies the number of times a frame is retransmitted before the 
link is reset. 


T1 

-1 through 51.1 (in tenths of a second:) 

3.0 

specifies the time, in seconds, to wait for a frame 
acknowledgement. 


T3 
1 through 511 


3.0 


specifies the number of seconds to wait for a response to a link 
reset. 


packet size 

64 through 1024 

128 

specifies the maximum number of octets (characters) to be 
transmitted in a single packet. 


collect 

yes, no 

no . 
specifies that all outgoing calls from a given x.25 multiplexer 
are to be made collect; i.e., the receiving system is to pay the 
network charges. 


packet threshold 

2 through 1025 

packet size+1 

specifies the minimum length of a "long packet". The multiplexer 
Will not output aiong packet if tnere are any snort packets 
queued for output. The effect of this is to optimize the 
transmission of short packets such as might be used _ to echo 
character-at-a-time input. The default value of one greater than 
the maximum packet size has the effect of disabling the 
preferential treatment of short packets. 


For example, if a number of Emacs users are sharing a network 
connection with an output-intensive application such as Inter- 
Multics File Transfer, the site may want to set the packet 
threshold to a small value in order to give the 1- to 3-character 
packets used to echo input priority over the large packets 
generated by the file transfer application. 
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name: window size 


values: 1 through 7 

default: 2 

meaning: specifies the window size W to be used in communicating with the 
network. 

name; local address 

values: 1 to 15 decimal digits 


default: none 

meaning: specifies the local address to be used in call request packets. 
This parameter has no default value; if no value is specified, 
none is used. 


name: network 

values: tymnet, datapac 

default: none 

meaning: specifies which set of national parameters will be assumed. This 
parameter has no default value; if no value is specified, none is 
used. 


name: n le 

values: 1 through 4095 

default: none 

meaning: specifies the number of X.25 logical channels to be defined. 
This parameter has no default value and must be specified. 


name: d_ bit 

values: yes, no 

default: yes 

meaning: specifies whether the network supports the use of the D bit for 
end-to-end acknowledgement. 


CONNECTING TO A FOREIGN SYSTEM THROUGH A PROTOCOL CONVERTER 


A user logged into Multics on an asynchronous terminal can talk to a 
foreign system by attaching to a protocol converter through subchannels on an 
FNP. Any incompatibilities between the terminal type and the foreign system are 
made transparent by the protocol converter. For example, the Renex Protocol 
Converter, Model RT9B, manufactured by the Renex Corporation of Springfield, 
Virginia, can be used to connect Multics to an IBM system, by simulating a 3270 
terminal controller. 


The connection is made through the services of the dial out facility, by 
specifying either the dial out or connect command to a generic destination, 
thereby causing a privileged attach of a slave channel with a matching 
destination. Alternatively, a dial out over an autocall channel can be 
effected, but this requires that a specific destination be supplied. The 
dial_ out and connect commands are described in detail in the Commands manual. 


Tne generic destination statement is part of the CMF charnel entry (see below). 


Once the connection is established, data transmission may commence between 
the two nodes at a speed appropriate to the configuration (i.e., the FNP and the 
protocol converter in use). A wait request is available for use with dial out 
exec coms, which allows for synchronization of transmissions from the foreign 
system (see the description of the dial_out command in the Commands manual). 


Channel Definition for Foreign System Connections 


Typically, a number of channels are hardwired between the Multics FNP and 
the protocol converter. Their CMF entries include a generic destination 
Statement to be specified in the dial_out command. A sample excerpt from the 
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CMF is shown below; note that the channel-names can be arbitrary. For a 
complete description of the CMF, see Section 4. 


name: a.h006; 

terminal type: ascii; 

baud: 9600; . 

attributes: hardwired, dont read answerback; 

generic destination: IBM1; _ - 

service: slave; 

comment: "connection to IBM system through Renex protocol converter"; 


name: b.h102; 

terminal type: ascii; 

baud: 9600; 

attributes: hardwired, dont read answerback; 

generic destination: IBM1; _ 

service: slave; 

comment: "connection to IBM system through Renex protocol converter"; 


This excerpt defines two channels connected to an IBM system through a 
Renex protocol converter that simulates a 3270 terminal controller. By entering 
the dial out command to the generic destination (dial out IBM1), the user can 
attach whichever line is available to communicate with the IBM system. 


ee | ee 


Sometimes the channel requires special initialization before communication 
can be established (this usually depends on the compatibility between the 
terminal type and the foreign system). Thus, a protocol converter commonly 
determines the user's terminal type so that any necessary mapping of terminal 
functions can be performed before the connection is established. 


‘When terminal conditioning is required, the user enters’ the connect 
command, rather than the dial out command, to the generic destination (connect 
IBM1, for the excerpt above), which automatically executes a site-supplied 


dial ant eyec com (TRM1 dial ont in this pasa) ta ner form tha annronriata 
SASS ey we Se Fe NX baviat Lc a ata) pS S ee ae way ww ree mae “ way apes Ee vu 
Startup functions. The connect command bypasses any existing user dial out 


Start_up exec com, searching the dial out search list as follows: 


-working dir 
>udd>Luser project]>dial out dir 
>site>dial out dir 


A sample dial out exec com to start up communications on a line attached 
through a Renex protocol converter is shown below. 


&version 2 

&trace off 

ke 

&- Translate terminal type to Renex terminal type number. 

&- If the terminal type is not supported by Renex, 

&=- generate XX for the terminal number. 

&= 

&set renex type 

&+ &Le before 
&+ &Le after 
&+ :VIP7200:03:VIP7201:03:VIP7205:03:VIP7801:03 

&+: VIP7803:03: VIP7804:03: ADM3A :06: HAZELTINE1500:02 
&+ >HP2621:09:1BM3101_1X:01: 1BM3101_2X:01:TV1920:05 
&+:TV1950:05:VT52:01:VT100:01:[e user term _type]:XX: 


&+ :[e user term type]: j 
&+ 2] 
eo 
&- Wake up Renex converter. 
&e 


12/83 A-23 CC75-01B- 


12/83 


send \015 
Re 
&- If the terminal number is XX, display the Renex 
&=- terminal menu and let the user decide what to do. 
an 
&if &Le equal &(renex type) XX] &then &quit 
&else &do 
= 
&- User terminal type is known. Discard the Renex menu 
&- and tell the Renex converter what the terminal is. 
-. 
..file output [pd]>é&! 
wait "ENTER TERMINAL NUMBER, 2 DIGITS." -time 20 
..ro; dl [pd]>&! 
send &(renex type) 
&end 
&quit 


A-24 


CC75-01B 


MULTICS COMMUNICATION SYSTEM-MEMORY CONFIGURATOR 


This appendix provides a Multics Communication System memory configurator 
which can be used to approximate maximum memory utilization on the DN355, DN6632, 
and the DN6670 front end processors. 


- 


The calculations outlined in Steps 1 through 5 apply only to FNPs configured 
for 32K of memory. 


The calculations outlined in Steps 6 through 11 apply only to a DN6670 
configured with at least 54K of memory. 


Many terms and mechanisms that are referred to in this appendix are described 
in the Multics Communications System manual (Order No. AN85). 


FNP CONFIGURED WITH 32K OF MEMORY 


me a ee 


1. Table 1 lists those modules that are required to be in the image. 
Also included is the memory required to support the IOM table and 
interrupt vectors. The init module is released for buffer space at 
the end of FNP initialization and is not to be included in the total 
count. The FNP requires around 30 buffers for DIA queues and other 
Support operations and this is included in the minimum buffer pad 


entry. 
TABLE 1 

MODULE LENGTH TOTAL 
‘control tables H 1806} 1806} 
idia man H ZHO4} 3404} 
finterpreter H 1986} 1986} 
'scheduler \ 13321 13321 
futilities H 26121 2612! 
iminimum buffer pad H 960} 960! 
jinterrupt vect H 5121 512} 
jiom tables H 321 323 
finit ; 3604} H 
62h See aes ee Se Se a es Se eS 1 

Bee ae ee 
} 

7 

! 


SubTotal } 12644 
I 
H 
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Table 2 lists the modules that a site may optionally configure based 
on the CDT and other site requirements. Refer to Section 6 of this 
manual for details of when one of these should be included. Sum the 
TOTAL column and enter result in the box after SubTotal?2. 


a A. Ble 2 


MODULE LENGTH TOTAL 
Tacu tables ett Ti?) 
‘ards tables H 674} { 
jautobaud tables H 2521 H 
} breakpoint man H 220} i 
{bse tables H 2358) H 
‘console man H 476} H 
ig115 tables H 1884} i 
1ibm3270 tables H 616} i 
tic sampler H 2090} 
‘hsla man H 38381 1 
'lsla man H 18723 i 
tmeters H 112} H 
1polled vip tables H 1258) 
}printer trace i 1208} H 
't202 tables H 546; H 
thasp tables H 980} 
itrace H 546} 
‘trace buffer H H H 
‘vip tables 5321 
' fe 1 I 1 
1 1 i I 
Se ee Se SD robe a Se 

| i] 
i i 


Table 3 determines the amount of memory required to support the various 
types of channels and devices. Echoplexed channels for this discussion 
are those which use any one of the following modes: echoplex, crecho, 
lfecho, or tabecho. A blank is provided in the table to enter the 
number of each type of channel or device. Multiply this number by the 
number in the third column and place result in fourth column. Sum the 
entries in the "memory required" column and enter result in the box 
after SubTotal3. If metering is enabled, an additional 42 words is 
required for each channel. 


NOTES: On the line labeled "LSLA device", enter the number of LSLAs 
configured on the FNP. 


On the line labeled "HSLA device", enter the number of the 
HSLAs configured on the FNP. 


The following abbreviations are used below: 


TIB = terminal information block 

TB tbl = TIB table entry 

TB ext = TIB extension buffer 

SFCM = software communications region 

IO buf = input, output, and echo buffers 
JP tbl = jump table 

HSLA = high speed line adapter 

LSLA = low speed line adapter 
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type of channel 


'echoplexed LSLA 


}non-echoplexed tty HSLA 
;echoplexed tty HSLA 


1115 protocol 


}polled vip protocol 


;}ibm2780 protocol 
1 ibm3780 protocol 
tHASP protocol 
|LSLA device 
1HSLA device 

t 


Legend: 


Legend: 


Legend: 


NOTE 1: 


Legend: 


Legend: 
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TABLE 3 
number memory/ memory 
channels X ehannel = required 
Bee Ce ae aides | 
Ks 856. (23° 4 
1 te oETe. C3y> 4 
i 1 210 (4) | 
H i -552. So) 4 H 
(6) | 
SI. CT) A 
i ST Oe 4 
(9) | 
LE) . tao €10)° | 
H 97 (11) | 
an ~ “SubTotal3 3 aaa 
42 Legend (2); s TIB 42 
2 TB tbl 2 
80 TO buf 112 
124 156 
5y Legend: (4) = SFCM 54 
42  TIB He 
2 TB tbl 2 
80 IO buf At2 
178 210 
54 Legend: (6) = SFCM 54 
42 TIB 42 
2 TB tbl 2 
16 TB ext 24 
438 TO buf | 
a Not 
552 
size in words of one VIP7760 I/0 buffer is 


(max_message len/2 + 2)*3 


Enter the above result into "IO buf." 


(7) 


(9) 


= SFCM 
TIB 

TB tbl 
TB ext 

IO buf 


SFCM 
TIB 
TB tbl 
TB ext 
TB buf 


54 Legend: 
Ho 
2 
32 
384 


514 


54 Legend: 
HQ 
2 
32 
see 
“Note 2 
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one output and two input. 


(8) 


SFCM 
TIE 
TB tbl 
TB ext 
IO buf 


SFCM 
Io buf 


(10) 


| | eontrolled by the 
max message len specification in the TTF entry for the multiplexer. The 
following accounts for three buffers: 


CC75-O1A 


% 


Legend: (11) = JP tbl 97 


oF 


NOTE 2: The size in words of one HASP I/O buffer is expressed by 
2 + block size/2 


where there are two words of buffer overhead and block size is specified 
by the TTF entry of the multiplexer. Enter the above result into "IO 
buf." 


NNR OR 


The above HSLA asynchronous I/O buffer entries include two mini-buffers for 
input. Each mini-buffer is eight words long to hold 14 characters and one word 
for housekeeping. These entries do not apply to those channels which operate in 
block transfer mode. Two input buffers are assigned to each channel in block 
transfer mode. The length of each buffer is set to hold at least 0.1 second of 
transmission (in whole 32-word blocks). A 32-word buffer speeds up to 4800 
baud, 64-word buffer to 9600 baud, etc. 


Only one input buffer is assigned on LSLA channels when the first character 
of a line is received. The value used (16 words) for the LSLA I/O buffer 
entries assumes that half of the LSLA channels have received input which is less 
than 60 characters. 


All asynchronous channels are given two output buffers in the above I/0 
buffer entries. It has been shown that an FNP running with all channels generating 
traffic services all channels smoothly if two output buffers are assignable to 
each asynchronous channel. 


An echo buffer of 32 words is assigned to each channel that is operating 
with any of the following modes turned on: echoplex, crecho, lfecho, or tabecho. 


4H, Calculate the sum of SubTotal1, SubTotal2, and SubTotal3. Subtract 
this sum from 32768. The result is the amount of free buffer space. 


5 It is possible that there may not be enough memory available during 
FNP initialization. This occurs while init is still executing and 
allocating TIBs and SFCMs. Table 4 and Table 5 help determine if too 
many channels are configured given the core image size in SubTotali 
and SubTotal2. 


Enter the appropriate numbers into the "number channels" column. Perform 
the multiplication and enter the results into the "memory required" 
column. Sum the "memory required" column and enter the result into 
the box after SubTotal4. 
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number memory/ memory 

type of channel channels X channels = required 
i:LSLA device (<6) t ! 766 1 1 
iLSLA channels 1 H 42 
1HSLA device (<3) i 97 i 
'HSLA channels H 96 
1 t t J | 
t ‘ t 4 : 4- { 
Subtotals ~ > 
1 | 
! | 


If there are no LSLA devices configured, strike out the "LSLA 
initialization code" entry in Table 5, since the code to initialize 
LSLA devices is released prior to TIB and SFCM allocation. 


Insert the previously determined values for SubTotal1l, SubTotal2, and 
SubTotal4. 


TABLE 3 


rSubTotall H T 
SubTotal2 

SubTotal4 

basic size of init 

LSLA initialization code 


ee ee ee ee 


SubTotal5 


ee cee ee ee ee me 


If SubTotal5 is over 32768, FNP initialization fails. If itis close, initialization 
may fail. This depends on where buffer boundaries are in relation to the boundaries 
of the executable code that is released in the init module. 


DN6670 CONFIGURED WITH AT LEAST 64K OF MEMORY j 


6. Table 6 lists those modules that are required to be in the image of a 
DN6670 with at least 64K of memory configured. Also included is the J 
memory required to support the IOM table and interrupt vectors. The 
init module is released for buffer space at the end of FNP initialization 
and is not to be included in the total count. The FNP requires around 
30 buffers for DIA queues and other support operations and this is 
included in the minimum buffer pad entry. 
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“TABLE 6. 


nS TOLAIO TO BORD 


MODULE LENGTH TOTAL 
control tables Y 1840 3 T8HO | 
ihsla_man | 4568 | 4568 | 
‘dia man i 3738 | 3738 | 
1} interpreter + 2140 | 2140 } 
ees 1310 1310 
;utilities 1 3370 } 3370 ; 
iminimum buffer pad H 960 | 960 |} 
‘interrupt vect’ H 512 | 512 | 
jiom tables H 32 | 32 | 
ipaging windows i 512 | 512 | 
Pints 1 2750 | H 
i i] 

! 

1 

i 


Table 7 lists the modules that a site may optionally configure based 
on the CDT and other site requirements. Refer to Section 6 of this 
manual for details of when one of these should be included. Note that 
the trace buffer size is not included in this table. The trace buffer 
is allocated in the upper memory when 64K or more is configured. The 
maximum size of the trace buffer is determined in Step 11. Sum the 
TOTAL column and enter result in the box after SubTotal7. 


TABLE T 


MODULE LENGTH TOTAL 
Yacu_ tables = =——i‘“—™*CStC*~*~‘“‘«‘«x BG 
‘ards tables 6743 
jautobaud_ tables 282} 
ibreakpoint man 224; 
ibse tables 24401 
iconsole man 480} 
ig115_ tables 1960} 
1ibm3270_ tables 6503 


| 
| 
| 
1 
{ 
{ 
1 
1 
1 
{ 
‘ 
H 
‘meters H 122} 
1 
H 
' 
t 
i] 
i] 
i] 
t 
i] 
1 


iic_ sampler 2104} 
;polled vip tables 1384} 
it202 tables 546} 
thasp tables 986} 
1x25 tables 4098 | 
| trace 2541 
ivip tables 532) 
{ 
tea o eee eee Lee ee beudeeooe Wado att 
SubTotal7 {| H 
i 


Table 8 determines the amount of memory in the low-order 32K required 


to support the various types of channels and devices. This space is 
made up of TIB table entries and TIB extensions. Echoplexed channels 
for this discussion are those which use any one of the following 
modes: echoplex, crecho, lfecho, or tabecho. A blank is provided in 
the table to enter the number of each type of channel or device. 
Multiply this number by the number in the third column and place 
result in fourth column. Sum the entries in the "memory required" 
column and enter result in the box after SubTotal8. Additional space 
is not required for metering in an extended memory configuration. 
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The following abbreviations are used below: 


TIB = terminal information block 


SFCM = software communications region 
HSLA = high speed line adapter 
TA BLE 8 
number memor y/ memory 

type of channel channels X channel = required 
itty oF 4 
1g115 protocol | { 18 3 ' 
ipolled vip protocol ! 26 | 
{ibm2780 protocol H 34 | 
}ibm3780 protocol ! ! 34 | 
'HASP protocol H H 34 | i 
1X.25 protocol H ; 36} : 
i}HSLA { 97 1 i 
| | | 
SubTotal | H 
1 ' 
J i} 


Calculate the sum of SubTotal6, SubTotal7, and SubTotal8. If it is more than 
32768, the FNP is over-configured,. 
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9. 


Table 9 determines how much space is required for I/O buffers. This 
Space is allocated in extended memory. Echoplexed channels for this 
discussion are those which use any one of the following modes: 
echoplex, crecho, lfecho, or tabecho. A blank is provided in the 
table to enter the number of each type of channel or device. Multiply 
this number by the number in the third column and place result in 
fourth column. Sum the entries in the "memory required" column and 
enter result in the box after SubTotal9. 


TABLE 9 
number memor y/ memory 


type of channel channels X channel = required 


non echoplexed tty | 6a] 


I i] 1 I 
fechoplexed tty 1 96 | 
12115 protocol i ; 438 | H 
polled vip protocol H iSee Note 4 } H 
'ibm2780 protocol ! 224 | 
1ibm3780 protocol ; 256 | 
1HASP protocol H isee Note 5 | } 
iX.25 protocol i ‘See Note 6 } 
I 1 i) { 1 
t I 1 | t 

~SubTotal9 $3 
! t 
1 1 


NOTE 4: The size in words of one VIP7760 I/0 buffer is controlled by 
the max_message len specification in the TIF entry for the 
multiplexer. The following accounts for three buffers: one 
output and two input. 

(max_message len/2 + 2)*3 


Enter the above result into the table. 
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NOTE 5: The size in words of one HASP I/O buffer is expressed by 
2 + block size/2 


where there are two words of buffer overhead and block size is 
specified by the TTF entry of the multiplexer. Enter the 
above result into the table. 


NOTE 6: The space required is a function of frame _size and the 
behavior of the protocol. The maximum space required is: 


(frame size/16)*(K+10) 


but the average is less than (frame _size*16)/K. 


The TIB and SFCM for each channel are allocated in a single 256-word 
page. Meters for the channel, if metering is enabled, are allocated 
in the same page, as are the permanent input buffers for asynchronous 
channels. The remainder of the page, if any, is included in the 
buffer pool. However, for safety and simplicity, the entire page 
should be counted against the channel. The space taken up for TIBs 
and SFCMs is therefore calculated as follows: 


number of channels x 256 = SubTotal10 


The maximum size of the trace buffer is determined as follows: 
calculate the sum of SubTotal9 and SubTotal10 and add 32768. Subtract 
the result from the total amount of memory configured. This result 
(or something less) can be used after the size key-word for the trace 
module in the bindfile for the FNP core image. 
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NOTE 6: Assuming the channel is operating at 9600 baud, the number of buffers 
per frame is expressed by 


buffers per frame = frame size/4064 
(to the next whole number) 


where the frame size (in bits) is specified by the TTF entry of the 
mitt $4 r. Ts 


The FNP could be holding one output frame, one input frame, and two 
input buffers. The total number of buffers involved is 


(2*buffers per frame + 2)*256 


Enter the above result into "IO buf." 


I/O Buffer Values for a DN6670 Configured with 64K of Memory 


er er ee ee ee 


All the above asynchronous I/0 buffer entries include two mini-buffers for 
input. Each mini-buffer is eight words long to hold 14 characters and one word 
for housekeeping. These entries do not apply to those channels that operate in 
block transfer mode. Two input buffers are assigned to each channel in block 
transfer mode. The length of each buffer is set to hold at least one-half 
second of transmission (in whole 32-word blocks). A 22-word buffer works for 
1200 baud, 64-word buffer for 2400 baud, and so on. 


All asynchronous channels are given two output buffers in the above I/0 
buffer entries. It has been shown that an FNP running with all channels generating 
traffic services all channels smoothly if two output buffers are assignable to 
each asynchronous channel. 


An echo buffer of 32 words is assigned to each channel that is operating 
with any of the following modes turned on: echoplex, crecho, lfecho, or tabecho. 


9. Calculate the sum of SubTotal6, SubTotal7, and SubTotal8. Subtract 
this sum from 32768. The result is the amount of free buffer space. 


10. The maximum size of the trace buffer can be determined from how many 
channels are configured. The TIB and SFCM allocation mechanism is 
constrained to keep the TIB and SFCM for a channel in the same page 
(256-word block) of memory. This allows TIBs and SFCMs for two channels 
to be allocated in one 256-word page. The following calculation can 
be used to determine how large the trace buffer can be given the 
channel configuration of the FNP: 


number 
channels x 128 = memory 
/ ] 120 ] t 


The product of the above calculation is the memory required to hold 
the TIBs and SFCMs. Subtract this product from 32768 and the result 
is the maximum size of the trace buffer. This result (or something 
less) may be used after the size key-word for the trace module in the 
bindfile for the FNP core image. 
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APPENDIX C 


SPACE REQUIREMENTS IN tty buf 


Two terms are defined to help make clear the data that will be presented 
later in this section: multiplexer channel--a channel that represents a concentrator 
controlling one or more channels; subchannel--a channel that represents the user's 
terminal or end device. All channels that are not multiplexer channels are 
considered to be subchannels. 


An FNP is a multiplexer to which, for example, a VIP7&801 can be attached. 
The full name of the channel would be something like "b.no24". The parent 
multiplexer name is "b" (the FNP), and the subchannel name is "h024". 


DATA BASES IN tty buf 


The space used by tty buf is occupied by various data bases that are used 
to maintain proper control of the Multics Communication Management. 


Static space is allocated in tty buf for output DCW lists for each FNP. 
This occupies 128 words for each loaded FNP (& DCW lists * 16 words per DCW 
LAST) 


The logical channel table (LCT) is also maintained in tty buf. Its size is 
determined by the number of channels configured in the CMF. “It is defined by 
the structures in the let.incl.pl1 inelude file. There is a 16-word header at 
the beginning of the LCT. Each channel (multiplexer or subchannel) requires a 
32-word entry (LCTE). 


A physical channel block (PCB) is configured for each channel of each FNP 
(names that match *.*¥, including multiplexers, but not subchannels of multiplexers), 
eight words per channel. 


A wired terminal control block (WTCB) of 20 words is allocated in tty buf 
for each subchannel. 


I/O buffers are dynamically created and deleted as needed. Each protocol 
makes different demands on tty buf space. (See "Dynamic Storage in tty buf" 
below.) 4 ial 
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STATIC STORAGE IN tty buf 


Subchannel and Multiplexer Channel Static Data Requirements 


ee 


FNP subchannels--For those subchannels of the FNP matching the star name *.*, 
the following is required: 


PCB 8 
LCTE 32 
WTCB 20 
Total 60 words 


VIP7760 multiplexer--This multiplexer type requires a data base in tty buf defined 
by the "pvmd" structure in the polled vip_mpx_data.inecl.pli include File. 


PCB 8 
LCTE 32 
PVMD 48 
Total 88 words 


VIP7760 subchannel--Each subchannel of a VIP7760 type multiplexer requires a 


data base in 


tty buf defined by 
polled vip mpx data.inecl.pl1 include file. 


LCTE 32 
PVSTE 4 
WTCB 20 
Total 56 words 


in the 


IBM3270 multiplexer--This multiplexer type requires a data base in tty buf defined 


by the "md" structure in the ibm3270 mpx_ data.incl.plt include file. 


PCB 8 
LCTE 32 
MD 64 
Total 104 words 


IBM3270 subchannel--Each subchannel of an JBM3270 multiplexer requires a data 
base in tty buf defined by the "mde" structure in the ibm3270 mpx data.incl.pl1 
include file. s > 


LCTE 32 
MDE 12 
WTCB 20 
Total 64 words 


2/83 C-2 CC75-01A 


X.25 multiplexer--This multiplexer type requires a data base defined by the 
"x25d" structure in the x25 data.inel.pl1 include file. 


LCTE 32 

X25D 32 

Total 64 words 
X.25 subchannel--Each X¥.25 subchannel of an X.25 multiplexer requires a data 
base defined by the "xsce" structure in the x25 data.incl.pl1 include file. 

LCTE 32 

XSCE 14 

WTCB 20 

Total 66 words 


X.25 logical channel--Each logical channel of an X.25 multiplexer (defined by 
the n le parameter) requeves a data base defined by the "xlee"™ structure in 
x25 data.inel.pl1 include file. 


LCE 28 
Total 28 


HASP multiplexer--This multiplexer type requires a data base defined by the 
"hmd" structure in the hasp mpx_data.inel.pl1 include file, 


PCB 8 
LCTE 32 
HMD 56 
Total 96 words 


HASP subchannel--Each HASP subchannel of a HASP multiplexer requires a data base 
defined by the "hste" structure in the hasp mpx data.incl.pl1 include file. 


LCTE 32 
HSTE 30 
WTCB 20 
Total 82 words 
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Calculation of Static Storage in tty buf 


mm eee 


The following chart outlines the required data needed to find out how much 
Static storage is required in tty buf. The data is obtained from the CDT. 


memor y/ memory 
type of channel number X channel = required 
1 C ty buf header o, \ aia 1 es i elk he I 
{DCW lists H 1 128 
{LCT header H { - 16 | 
}spare channel count in CDT } { 32 { : 
| FNP subchannels H i 60 
tHASP multiplexers H 96 H H 
}HASP subchannels { H 82 H 
| IBM3270 multiplexers H H 104 H H 
1 1BM3270 subchannels H H 64 H H 
iVIP7760 multiplexers 1 i 88 H i 
}VIP7760 subchannels H H 56 H i 
iX.25 multiplexers H 1 64 1 i 
1X.25 subchannels H H 66 H H 
1X.25 logical channels H H 28 H H 
1 1 t i] ! 
{ 1 i ' i] 
ie ey Tog aaa Gs ot SO Ga: A a 
§ 1 
' i 


DYNAMIC STORAGE IN tty buf 


It is difficult to predict what demands the users of a system will place on 
the available 1/0 buffer space in tty buf. This has to be measured with 
system comm meters. It has been found that tty buf should not run more than 80% 
full to handle peak loads best. = 


Delay queues are also dynamically allocated in tty buf and can crash the 
system if there is no room for them. These are transactions that the host is 
requesting the FNP to perform. If there is no mailbox to put the transaction 
into, it is entered into the delay queue for later processing. 


Some comments can be made about each protocol's handling of its I/O buffer 
Space in tty buf. Only an actively operating line will require I/0 buffer space 
in tty buf. The following calculations should only be performed on the number 


of channels expected to be active at any one time. 
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Buffer Size When Controlled by Baud Rate 


mee ee 


The output buffer size is sometimes controlled by the baud rate of the 
channel. This occurs as noted in the following sections. 


Whether a given block of data is delivered all at once depends on the 
available space in ring 9 and in the FNP. 


At speeds of 4800 baud and below, no more than 960 characters are sent to 
the FNP at a time. However, you can adjust the baud rate FNP entry in the CMF 
(see "FNP Entries in the CMF"). When required, use the following equations to 
determine the size of the buffer. 


If the baud rate of the channel is below 1200 baud, assume it is 1200 baud 
for the following calculations. Each buffer has a one-word header containing 
the address of the next buffer and the number of characters in the buffer. 

buffer char size = min((64 * baud/1200)-4, 508) 

The following equation expresses the size of the buffer in words: 


buffer word size = buffer _char_size/4 


ASYNCHRONOUS I/O BUFFER SPACE 


Input buffer size is 16 words when channel is not operating in block transfer 
mode. If the channel is operating in block transfer mode, the buffers will be 
based on the baud rate of the channel. Output buffer size is based on the baud 
rate of the channel (see discussion above). The following formula accounts for 
one input buffer and one output buffer: 


if in block transfer mode; 
ASYN€-I0 = buffer _word size * 2 


G115 I/O BUFFER SPACE 


Entry in table accounts for two buffers. 


HASP I/O BUFFER SPACE 


The size of HASP buffers in tty buf is controlled by the block size parameter 
in the TTF entry of the multiplexer. An active HASP multiplexer will most 
likely have three blocks in tty buf: two for output and one for input. 


HASP-I0 = 3 * ttf block size 
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IBM2780 AND IBM3780 I/O BUFFER SPACE 


The size of a buffer is controlled by the value following the -size control 
argument in the attach description to bisyne_. The following formula accounts 
for two buffers: 


IBM2780/3780-10 = ((block size/4) + 1)*2 


IBM3270 I/O BUFFER SPACE 


Entry in table accounts for two buffers. 


VIP7760 I/O BUFFER SPACE 


The buffer size is controlled by the max message len specification in the 
TTF entry for the multiplexer. The following accounts for two buffers: 


VIP7760-I0 = (max_messsage len/4 + 1)*2 


&.25: 1/0--BUFFER SPACE 


Data is transmitted and received in frames. Each frame occupies as many 
buffers as necessary to hold the frame. The size of the frame is controlled by 
the frame size parameter specified in the TIF entry of the multiplexer. 


Buffer size for X.25 multiplexers is based on the baud rate of the channel 
(see above). The frame size parameter in the TTF entry is used to determine the 
number of buffers that will hold the frame. 


buffers per frame = (frame size/&)/buffer char size 
(to the next whole number)” a1 


Now the number of words used by each frame can be calculated, 

frame words = ((buffer_char_size/4)+1)*buffers per frame 

The X.25 protocol allows up to 7 frames to be transmitted before an 
acknowledgment needs to be received to send more frames. This is controlled by 
the window size parameter in the TTF entry of the multiplexer. It is possible 
that there would be one output window waiting to be acknowledged plus two output 
frames being filled in by the multiplexer. Two input frames should also be 
allowed for. The total number of words for each X.25 multiplexer will be: 


X25-I0 = (window size + 4)*frame words 
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Calculation of Dynamic Storage in tty buf 


ee eee 


memory/ memory 

type of channel number X channel = required 
;ASynchronous 1/0 buffer space | ) 1 ~ ASYNC=LO:% ee 
iG115 1/0 buffer space } H 170 | H 
1HASP I/O buffer space | ' HASP-IO } H 
| [BM2780/3780 I/O buffer space } | IBM2780/3780-I0 } 
1IBM3270 I/O buffer space 1320.4 
IVIP7760 I/O buffer space | VIP7760-I0 } 
i1X.25 I/O buffer space X.25-10 

' 

i i i t ' 
pow gr 4s ees he ee Total fe er H 
! 
| 


2f33 C-7 CC75-O1A 


MULTICS ADMINISTRATOR’S MANUAL 
COMMODNICATIONS 
ADDENDUM B 


SUBJECT 
Additions and Changes to the Manual 


SPECIAL INSTRUCTIONS 
Refer to the Preface for “Significant Changes.” 
This is the second addendum to CC75, Revision 1, dated July 1982. 


Insert the attached pages into the manual according to the collating instruc- 
tions on the back of this cover. Throughout the manual, change bars indicate 


new and changed information; asterisks denote deletions. These changes will 


be incorporated into the next revision of this manual. 


Mave. 


Note: 


Insert this cover behind the manual cover to indicate the updating of this 
document with Addendum B. 


SOFTWARE SUPPORTED 
Multics Software Release 10.2 


ORDER NUMBER 
CC75-01B December 1983. 


39104 
1183 
Printed in U.S.A. 


Honeywell 


COLLATING INSTRUCTIONS 


To update the manual, remove old pages and insert new pages as follows: 


Remove 


iii through vi 
vii, blank 


j-1 through 1-4 
2-3, blank 

4-3 through 4-6 
4-6.1, blank 
4-7, 4-8 

4-9, blank 

5-3, 5-4 

6-3, 6-4 

T-1 ? T-2 


7-21 9 T-22 


8-11, 8-12 
Aa Ae? 
A-5, A-6 
A-17, A-18 


Ao24. “Ke22 
B-5 through B-8 


i-1 through i-4 


The information and specifications in this document are subject to change without notice. This 
document contains information about Honeywell products or services that may not be available 


Insert 


iii through vi 


1-1 through 1-4 


2-3, blank 


4-3 through 4-10 


5-3, 5-4 
6-3, 6-4 
T-1 ? T-2 


7-21, blank 
7-21.11, 


Ba443,.:8512 
Ants “AH2 
A-5, A-6 


A-17, blank 
A-17.1, 


A-21 through A-24 


B-5 through B-8 


i-1 through 


outside the United States. Consult your Honeywell Marketing Representative. 


© Honeywell Information Systems Inc., 1983 
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MULTICS ADMINISTRATORS’ MANUAL 


COMMUNICATIONS ----- 


ADDENDUM A 


SUBJECT 
- Additions and Changes to the Manual 


SPECIAL INSTRUCTIONS 
Refer to the Preface for “Significant Changes.” 
This is the first Addendum to CC75, Revision 1, dated July 1982. 


Insert the attached pages into the manual according to the collating instruc- 
tions on the back of this cover. Throughout the manual, change bars indicate 
new and changed information; asterisks denote deletions. These changes will be 
incorporated into the next revision of this manual. 
Note: 


Insert this cover behind the manual cover to indicate the updating of 
this document with Addendum A. 
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Multics Software Release 10.1 
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36095 


Printed in USA Honeywell 


COLLATING INSTRUCTIONS 


To update the manual, remove old pages and insert new pages as follows: 


Remove 


iii through vi 
vii, blank 


2-1, 2-2 


4-1 through 4-8 


6-1, 6-2 
6-5, 6-6 


7-11, 7-12 
T2195. 720 


A-17 through A-20 


B-1 through B-8 
B-9, blank 


C-1 through C-6 


i-1 through i-4 


Honeywell disclaims the implied warranties of merchantability and fitness for a partic- 
ular purpose and makes no express warranties except as may be stated in its written 
agreement with and for its customer. 


In no event is Honeywell liable to anyone for any indirect, special or consequential 
damages. The information and specifications in this document are subject to change 
without notice. 


(c) Honeywell Information Systems Ine., 1983 
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active channel 5-2 


analog signal 3-3 


answerback 2-3 


answering service 3-2 


asynchronous I/O buffer space C-5 


asynchronous line type 2-1 


asynchronous link 3-1 


attach command 1-4, 5-2 


baud rate 2-3, 3~1 
automatic detection 

1200 baud 3-5 
modems 3-6 
other bauds 


3-3 


3-5 
bindfile segment 7-2 


bind_fnp command 1-4, 7-2 


CDT 
see channel definition table 


channel 
addition of 5-1 
attach command 5-2 
attributes 5-3 
changing the attributes of 5-2 
changing the service type of 5-4 
changing the state of 5-2 
deletion of 5-2 
detach command 5-3 
line type 2-2 
modification of 5-1 
multiplexer C-1 
naming 1-3 
remove command 5-3 
service type 4-6, 5-4 
inactive 5-2 
login 3-2 


terminal type 2-3 


channel definition table 1-1, 1-3, 
2-2, 2-3, 3-2, 4-1, 5-1, 7-11, 
7-27 
channel master file 4-1, 5-1, 7-11 
defaults 4-7 
example 4-8 


global statement 4-2, 4-7 


INDEX 


channel master file entry 4-2 


channel comm meters command 


channel 
access class statement 
answerback statement 
attributes statement 
baud statement 4-4 
charge statement 4-6 
comment statement 4-7 
dataset statement 4-6 
generic destination statement 
initial command statement 4-7 
line type statement 4-5 
multiplexer type statement 
name statement 4-2, 4-3 
service statement 4-6 
terminal type statement 

FNP 
FNP statement 4-2 
hsla statement 4-2 
image statement 4-3 
lsla statement 4-2 
memory statement 4-2 
service statement 4.3 
type statement 4-2 


yoy 
a5 
yoy 
4-3 
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4-5 


CMF 


see channel master file 


command descriptions 


communications channel 


bind fnp 7-2 


channel comm_meters 7-4 
console report 7-8 

ev emf 7-11 

display edt 7-12 
display fnp idle 7-14 


fnp_ throughput 7-16 

map355 7-18 

mes version 7-19.1 

meter fnp idle 7-20 

set x25 packet threshold 7-21.1 
system_comm_meters 7-22 

tty dump 7-24 

tty lines 7-27 


1-1 


communications link 3-1 


communications protocol 


concentrator 
eonfig deck 


eonfigur ation 


asynchronous 
synchronous 


3-1 
3-1 


T-4, 2-1 


1-2 
1-4, 5-5 
1-3 


console report command 7-8 


control tables module 


core image 


1-4 
1-4 


core image segment 7-2 
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ev_emf command 4-1, 5-1, 7-11 


D 
dataset 
see modem 
detach command 1-4, 5-3 
dialup link 3-2 
digital signal 3-3 


display _cdt command 4-1, 7-12 


display fnp_ idle command 7-14 


FNP 
see Front-End Network Processor 


FNP core images 6-1 
bindfile 6-4 
key words 6-4 
sample 6-6 


modifying 6-1 
optional modules 
required modules 
using 6-1 


FNP global statements 
FNP_required up time 
Spare channel count 


4 


4-7 
-7 

4-8 

fnp throughput command 7-16 


foreign system connections A-22 

Front-End Network Processor 

1-4, 3-1, 4-1, 5-1, 5-5 
crash notification 5-6 


1-1, 1-3, 


full duplex 3-2 


G115 I/O buffer space C-5 


GCOS Environment Simulator 7-18 


generic destination A-22 


half duplex 3-2 


hangup operation 3-2 
hardwired link 3-2 

HASP I/O buffer space C-5 
HASP workstations A-~1 


host systems A-1 


IBM 3271 terminals A-5 


IBM2780 and IBM3780 I/O buffer space 
c-6 


IBM3270 I/O buffer space C-6 


inactive channel 5-2 
initialization 1-3 
multics command 
startup command 


install command 4-1, 5-1 


LCT 

see logical channel table 
line protocol 4-6 
line type 1-4, 2-1 


2-2, 2-3 
characteristics 1 


? 
e- 


listen operation 3-2 


load_mpx command 4-7, 5-1 


logical channel table C-1 


login command 2-3 


map355 assembler language 7-18 


map355 command 7-18 

mes version command 7-19.1 

memory configurator B-1 

DN355 B-1 

DN6632 = B-1 

DN6670 = B-1 

DN6670 configured with at least 64K 

memory B-5 

FNP configured with 32K memory B-1 

I/O buffer values B-4 


meter _fnp_idle command 7-20 
modem 1-3, 2-1, 3-2, 3-3, 4-6 


modulator/demodulator 
see modem 


MPX_meters subroutine 8-6 
multiplexer 1-2, 4-1, 5-1, 5-5, A-1 
channel C-1 
deletion of 5-5 
HASP 


multiplexer terminal types 
HASP channels A-2 
HASP workstations and host systems 
FNP Core Image A-1 


multiplexer terminal types 


A-3 


AR 
ani 


subchannel terminal types A-4 
IBM3270 A-5 
channels A-6 
FNP Core Image A-6 
see also FNP Core Images A-6 
multiplexer terminal types A-6 
raw3270 mode A-9 
subchannel terminal types A-8 
typing conventions A-8 
polled VIP A-10 
blank lines A-15 
channels A-16 
circumflex and tilde A-16 
dialups and hangups A-16 
end of page A-=-15 
FNP Core Image A-10 
see also FNP Core Images A-10 
formfeedsS A-15 
function codes A-14 
input size considerations A-13 
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multiplexer (cont) start _mpx command 5-5 
polled VIP 


multiplexer terminal types A-11 Static space C-1 
quits A-14 
subchannel terminal types A-13 stop bit 3-1 
tabs A-15 
software-simulated terminals A-16 stop mpx command 5-1, 5-5 
channels A-17 
multiplexer terminal types A-17 subchannel 5-5, C-1 
X¥.25 network connections A-17, 
4-17.1 Subroutines 68-ij 
ehannels A-=-19, A-20 comm meters 8-2 
FNP Core Image A-19 metering gate $comm_chan_star_list 
hardware A-18 8-10 > ~ = 
link level. A-+8 MPX meters 8-6 
packet level A-18 phes $get comm meters 8-12 
software A-18 ~ as ~ 
terminal control level A-19 synchronization character 3-1 


terminal type file (TTF) A-20 
synchronous line type 2-1 


N system_comm_meters command 7-22 
names T 
channel 1-3 
network connections terminal type 1-4, 2-1, 2-3 
X.25 A-17 characteristics 2-1 
terminal type file 1-4, 2-3 
6) 
terminal type table 1-4, 2-3 
object segment [7-2 TTF 
see terminal type file 
P : TTT 
see terminal type table 
parent multiplexer 1-3 tty buf C-1 
baud rate C-5 
parity bit 3-1 buffer size C-5 
dynamic storage C-4 
PCB ealculation C-7 
see physical channel block logical channel table C-1 
physical channel block C-1 
polled VIP terminals A-10 Static data requirements C-2 
Static storage C-2 
print terminal types command 4-5 calculation C-4 


wired terminal control block C-1 
private-line link 3-2 
tty dump command 7-24 
protocol 3-3 
asynchronous 3-3 tty lines command 4-1, 7-27 
synchronous 3-3 ial 


protocol converter A-22 V 


R value-added networks 
DATAPAC A-17.1 
TELENET A-17.1 
remove command 5-3 TYMNET A-+17.1 
UNINET A-17.1 
reset _cdt_meters command 4-1 
VIP7760 I/O buffer space C-6 


search rules segment 7-2 
wired terminal control block C-1 
send admin command command 5-1 
~ WTCB 
set_ttt_path command 2-3 see wired terminal control block 


set_tty command 2-3 


set_x25_ packet threshold command 
7-21.1 
X.25 I/O buffer space C-6 
software-simulated terminals A-16 
X.25 network connections A-17 
start bit 3-1 
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X.25 network connections (cont) 
specifications : 
channels A-20 
hardware A-18 
link level A-18 
packet level A-18 
software A-18 
terminal control level A-19 
TTF A-20 
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